The Soapbox

Face it. You'll never be able to shut me up.

 

Friday, August 26, 2005

MediaWiki Sysop User Account

It seems that I've managed to have yet another problem with my MediaWiki installation. After everything seemed to setup just fine, I tried to log into the system using the account that I had specified as a sysop account during setup.

Strangely enough, MediaWiki returned an error saying:

There is no user by the name ______

Hmm....that's funny. I guess the sysop account that I had specified during setup didn't 'take', or just wasn't added to the database. Oh well.

Rather than trying to attemp the setup process again, I decided to find an appropriate solution for the problem. First, I used my Wiki's create an account or login screen to add a user for myself. I used the same username and password that I had during the initial setup, and it didn't complain. I guess my sysop user really wasn't there.

Now that my account actually existed, I had to find a way to give it sysop and bureaucrat permissions in my Wiki. This, as I learned, can be most easily accomplished by editing the database directly, rather than monkeying around with MediaWiki's PHP code.

The table that must be modified is the user_rights table which should have been created by your MediaWiki setup (it was for me). This table contains the permissions applied to various usernames, and maps its user_id field to the user_id field in the user table. Thus, to edit some user permissions, all we have to do is find the appropriate user_id in the user table and then assign a new ur_rights value to this user_id in the user_rights table.

To discover what your user_id is you can use the following SQL query.

Select * from user

Then, just look for the user_idthat corresponds to the user (in my case, it was me) that you want to give sysop status to. Now you are prepared to run the following query. For our example, let's say that the user_id I wanted to change permissions for was 1. Here's what you do.

UPDATE user_rights SET ur_rights="bureaucrat,sysop" WHERE ur_user=1;

Presto! The user with user_id=1 has been made a sysop.
Thursday, August 18, 2005

MediaWiki Installation Help

I've recently been trying to get a Wiki set up on this website. While running the setup, MedaWiki returned the following errror;

Specified key was too long; max key length is 1000 bytes

when it tried it tried to create the categoryLinks table in my mySQL database. It took me quite a while to figure out the solution.

There are a couple things that need to be understood in order to understand why this error is happening.

  • UTF-8 encoding uses 3 bytes per character. Thus, the above problem will only occur when a database's encoding is set to UTF-8. This is unfortunate, because not all people will have an option to choose another encoding type for their mediaWiki installation.
  • In our case, there is a 1000 byte limit on keys.
Let's take a look at mediaWiki's SQL CREATE statement for the categoryLinks table so that we can pinpoint the problem.

CREATE TABLE wiki_categorylinks (
cl_from int(8) unsigned NOT NULL default '0',
cl_to varchar(255) binary NOT NULL default '',
cl_sortkey varchar(255) binary NOT NULL default '',
cl_timestamp timestamp NOT NULL,
UNIQUE KEY cl_from(cl_from,cl_to),
KEY cl_sortkey(cl_to,cl_sortkey(128)),
KEY cl_timestamp(cl_to,cl_timestamp)
)

At first glance, it looks like a perfectly legal SQL statement that shouldn't cause any problems. So where is our problem coming from?

If we look closer at the statement KEY cl_sortkey(cl_to,cl_sortkey(128)) we see that we are trying to create a key using cl_to and cl_sortkey. In this case, mediaWiki is only indexing the first 128 characters of sortkey. So how many bytes are we using for this key?

If we do the math, remembering that UTF-8 encoding uses 3 bytes per character we arrive at the the following calculation:

255+128=383
3*383 = 1149 bytes

So there's our problem. We're trying to create a key that is 1149 bytes long when we only have 1000 bytes to use. No wonder we're getting an error.

My solution was to change the CREATE statement in such a way as to bring this number down below 1000. Here's what I changed it to:

KEY cl_sortkey(cl_to(200),cl_sortkey(128))

This way, we're only taking the first 200 characters of cl_to to use in a our key. This may have adverse affects on MediaWiki, but I think the chances are pretty small. 200 characters is still quite a bit.

Let's check our math:

200+128=328
3*328=984


Since 984 is less than 1000, we should be fine. It worked for me, give it a shot. If it doesn't fix your problems, you can always drop the table and recreate it using a different workaround.

Disclaimer: This is not an official MediaWiki bug fix, as such, I will not be held responsible for any damages resulting from its use. I am in no way associated with the WikiMedia Foundation or the MediaWiki content tool.
Monday, August 15, 2005

Fixing Windows Update and Installation Problems in Windows XP SP2

There have been numerous people (including myself) who seem to be having the following problems with Windows XP. This bug seems to make Windows Update get stuck in the "Initializing Installation..." phase of its installs. Windows Installer packages also fail to complete installs successfully.

Affected Operating Systems
Windows XP Professional SP2 (service pack 2)
Other Windows XP versions? (unconfirmed)

Software Installed on Affected Machine
Norton Internet Security 2005 (up-to-date using LiveUpdate to Aug. 2005)
Microsoft AntiSpyware Beta (up-to-date to Aug. 2005)
All updates as suggested by Windows Update to Aug. 2005

Symptoms
The following symptoms have been observed in an affected system. None of the following symptoms resulted in a complete freeze. It was always still possible to work with other applications.
  • MSI packages fail to complete installs. Installation starts successfully, but halts without error at a non-determinate point in time.
  • Windows Installer fails to complete installs. Installation freezes without error. Windows Installer does not shut down, but does not proceed any further than a particular point in the installation. Symptoms observed in both Windows Installer 3 and Windows Installer 3.1.
  • Intermittent "access denied" errors when trying to access Windows utilities that should be available to an Administrator type account.
  • System Restore tab missing from My Computer -> Properties window when logged in as an Administrator type account.
  • Windows Update hangs indefinately on the "Initializing Installation..." phase of update procedure. No error provided.
  • Generally poor system performance when attempting to access Windows control panels and other system tools.
Predicted Cause(s)
  • Corrupted elements in Windows File Protection (WFP) structures.
  • Corrupted main system files usually under the protection of Windows File Protection.
  • Corrupted files in the C:\Windows\system32\dllCache folder.
  • Poor quality and poorly tested updates issued by the Windows Update utility that incorrectly patch main system files.
  • Norton Internet Security 2005 incorrectly handling protection of key system resources and damaging critical files.
Bug Identification
If your system is exhibiting any of the behaviors listed above in Symptoms, your system may be affected. A simple check for this problem can be completed as follows.
  • Right click on My Computer, then select Properties.
  • If your windows account is an Administrator account there should be a tab in the Properties window called System Restore.
  • If the System Restore tab is missing, your system may be experiencing the bug under discussion.
Resolution
The following steps can be followed to repair the system to get Windows Update and installations working again.
  1. Click Start -> Run.
  2. Run sfc /scannow. This will start the System File Checker (sfc.exe) to verify the integrity of main system files.
  3. If sfc requests insertion of the Windows XP cd-rom, insert your Windows XP cd and click Retry.
  4. sfc should complete its verification of the system files and close.
  5. Restart the system.
  6. Disable System Restore in My Computer -> Properties. Warning: This will delete all your previous restore points.
Your system should funtion normally now. Try running an installer, or preferably, a Windows Update package to verify correct functionality.

Notes
Once the fix is completed, it is not known whether turning System Restore back on will cause the problems to return.

Other Resources for Similar Bugs (in case the above didn't help)
http://support.microsoft.com/kb/898628
http://support.microsoft.com/kb/885894

Disclaimer
This is not an official Microsoft bug report, nor am I attempting to affiliate myself with Microsoft in any way. The Windows XP operating system, all its variants, and all its included utilities are the property of the Microsoft Corporation. It is Microsoft's duty to provide official bug reports and product updates for the Windows XP operating system, as such, I cannot and will not be held responsible for any damages or losses that you incur by following my repair suggestions.

Previous Posts

Archives

Support This Site

 

Powered By

 

Powered by Blogger