I’m in the process of setting up MediaWiki at work (the engine used for WikiPedia) as a test to see if we can use it for our documentation and manuals.

I hit a few problems along the way though, mostly down to inexperience with the software and not RTFMing. For reference I was installing the latest version of MediaWiki (1.5.6) on a Windows 2000 Server box (IIS 4 installed) with PHP 4.4.2 and MySQL 4.1.18. I had three main problems:

  • MySQL / PHP Old Password problems
  • Windows Access Rights / Permissions
  • Bugs in MediaWiki due to PHP on Windows working differently

I’ve hit the MySQL / PHP password problem quite a few times due to college stuff I’ve been doing but never got round to documenting it properly (I have now!). The usual error message you get back from PHP is Client does not support authentication protocol. Basically the problem is that MySQL now uses a new method for password encryption and PHP isn’t compatible with it. I find it a real pain in the backside that they’ve managed to engineer this kind of cock up. You end with passwords being stored that can’t be read properly.

To stop it happening you need to add old_passwords to the [mysqld] section of my.ini. Then restart the MySQL service for it to take affect. If you’re unfortunate enough to end up with broken passwords, the fix is to login to your MySQL database, work out which ones are using the new method and manually fix them. Like this:

  • Get list of users affected: SELECT Host, User, Password FROM mysql.user WHERE LENGTH(Password) > 16;
  • Fix their passwords (one at a time): SET PASSWORD FOR ‘some_user’@’some_host’ = OLD_PASSWORD(‘newpwd’);

The access rights were totally down to me not being awake. I’d remembered to set up script access in IIS, no problem, but I forget everytime to add the correct IUSR_MACHINENAME permissions. You have to add the local machines internet user to have different permissions to various folders (mostly just read access to the entire site, but write access to the images subfolder if you want to upload) and I must have been asleep, because to start with I was assigning the domain controllers IUSR and was wondering why it wasn’t working (by default Windows gives the user list of those on the domain, I should have selected the local machine). Once I got my brain into gear, after about 5 cups of Rocket Fuel, I got round it. 

At this point I was still getting errors on various pages with a PHP blurting out something along the lines of Undefined index REQUEST_URI. Turns out that in PHP for Windows you need to use SCRIPT_NAME instead of REQUEST_URI… obviously. So a bit of search and replace through the MediaWiki source code sorted that out (there were about 5 files).

After which, all was fine and dandy! Now I just need to get my head around how the system works!

Relevant Links:

By Paul

5 thought on “Wrestling with MediaWiki on Windows”
  1. I just got MediaWiki 1.5.8 installed on Windows Server 2K3 with SP1 (technically Small Business Server). Everything appears to be working as it should, but I presume I will run into some interesting issues as things move on–aside from the fact that at some point I will need to move the content elsewhere on my server as storage demands grow.

    This is much better than FlexWiki, since MediaWiki allows file uploads–attachments to pages will be quite important in this environment.

    How is the wiki going in your place of business?

  2. Jason,

    It’s going pretty well actually. We’ve not really hit any snags after configuring it. It’s been decided that we don’t want our end users to be able to edit any content so that’s been restricted down. I’ve also got to look into some method to make sure it’s only accessible to our customers. I think Windows folder permissions and various Windows accounts is the approach I’ll take for that.

    At the moment we’ve copied sections from various manuals and documentation in to get a feel for how MediaWiki works and what kind of style settings we want to implement.

    We’ve also been testing out various VB macros that can convert Word docs into MediaWiki text. We’ve yet to decide on one in particular and it looks like we will have to do some modifications, but that was to be expected. The same applies for uploads, we have quite a few screenshots and various filed we’d like to link and it would great to automate it.

    Once we’re happy with the formatting and changed the theme so it fits in with company colours etc, we’re going to move from our current test server to proper web box running W2K3.

    I’ve also got to take a look at MediaWiki to PDF converters since we do have customers that don’t have net access, so will need electronic copies of whatever we store in MediaWiki.

    All in all, it’s gone pretty smoothly. Progress has been a bit slow due to other work recently, but I think we’re definitely going ahead with it. What are you currently using MediaWiki for?

  3. Paul,

    Glad to hear the wiki experiment is going as smoothly as it is. I will probably need to tweak permissions for our wiki, but I have not even got that far in our implementation yet. I have been looking to get it to the point where it is accessible to all and have authentication straightened out.

    I just got through a bear of a time making the site accessibly outside of our internal network. Long story short, we have an ISA 2004 server that sits in front of everything else on our network. Nice to have, but makes configuring things like webservers a little bit more annoying than most. In my case, it was unable to see the internally hosted wiki. Now, it works from the outside, and I need to tweak it so it will work from the inside using the same URL.

    The only other thing I have been pondering is what to do about user authentication. I would prefer to force my users to login, and then have these logins work just the way I would expect them to in MediaWiki. How are you accomplishing this? Forcing my users to remember an additional username and password–not too big a deal–is not preferable.

    As for what we are currently using MediaWiki for, I plan for it to be our firm’s living breathing intranet. Administrators and such can post content, and my auditors–as I work for an accounting and auditing firm–can also post content. some organization method will need to be worked out, but I can see this as being beneficial. An easy way to share documents and hopefully make it a bit better than shuffling stuff around via email.

  4. Jason,

    I’ve not got much further with our usage of MediaWiki due to various things, but with regards to user logins, I was going to use Windows user accounts to do it. On a normal website you give the web servers Internet Guest Account (IUSR_MACHINENAME) access, but in this case you don’t. I’d change the folder access (via Explorer) for the MediaWiki site to particular users. That way they get a login prompt in their browsers.

    The snag you might have is that you’d need various extra MediaWiki logins to allow access to edit content etc. I don’t know if MediaWiki is capable of linking into Windows user accounts. I would say not given its background.

    For us this isn’t so much of a problem, since we’ll be the only ones internally editing the wiki. Our customers will just be viewing the content of the site, so will only have to login the once.

    I’d be interested to know what solution you come up with, since our requirements may change.

  5. Paul,

    Well, it appears I have made some progress on my attempts to get LDAP authentication to work against AD. It is working, but I am not getting any further than being prompted for authentication. I think I might need to do some tweaking as far as the binding is concerned–and some tweaking with a proxy agent.

    Additionally, I also wonder if I will need to create accounts. Perfect world would be that user authenticates, and the authentication is passed onto MySQL/Mediawiki. If the user exists and credentials are correct, carry on. If not, create the Mediawiki account to match, and carry on. This I think probably won’t happen in the near term.

    I also think that I may be forced to open it up without this authentication piece completely done. I would prefer folks to get rolling with the Wiki, and maybe this is something that will get resolved in time.

    As for controlling who edits where, I am not too worried about that. Admittedly, this is an internal-use intranet. Sure, it will be accessible from without and within, but the content is meant for our company. As a result, I am not too worried about restricting who puts content where. Additionally, as the wiki grows, order will naturally come about.

Leave a Reply

Your email address will not be published. Required fields are marked *