dangerOp on Xanga

Weblog

Sunday, 02 December 2007

sparse notes on upgrading wiki: PHP 5.2.5, MySQL 5.0.45

Upgrading PHP, MySQL and (possibly) Mediawiki itself. PHP is currently at 5.1.5, and MySQL is also a bit dated at version 5.0.24 . Thanks to our security audit coming up at the end of the year, it's time to get the updates in! yay, woohooo... yawn.

The PHP 5.2.5 MSI installer on a Windows 2003 Server/IIS6 system (using the ISAPI filter) will configure IIS with a link to the php library as e.g. "C:\PHP\php5is~1.dll". This needs to be changed into the full path such as "C:\PHP\php5isapi.dll". After this it will correctly find PHP. (This is changed in the IIS Manager, go to each of your website's properties, Home Directory tab, in the Application settings section there is a configuration button). Don't forget to do a custom install and enable the MySQL extension.

MySQL doesn't seem to upgrade cleanly over the older version. The troubling part lies in the "start service" of the re-install, which fails with no explanation why. The event log gives a cryptic answer about catching a signal 11 and quitting (Google has only 1 hit on this, of a user reporting this as a bug from about two years ago). The issue actually appears to be the residual files left in the Program Files\MySQL\MySQL Server 5.0 directory. Once you delete those and run the installer again, it starts up the service cleanly. For kicks, tell it to create a brand new database, and run the restore operation (bonus points for forgetting to do a backup... tsk tsk).

Mediawiki (old version 1.9.3) then has issues keeping you logged in. A test upgrade doesn't work, even with about 3 different permutations on the install dance (extra kudos for forgetting to backup... "there are two types of computer users: the paranoid and the inexperienced"). As an idea, I tried installing a new instance of the mediawiki software (Mediawiki 1.11), and the config script helpfully tells me that PHP does not have write access to the session directory (the PHP variable session.save_path). To fix this, go to the directory properties, sharing tab, and give the Network Service the ability to read and write (disable the others as a precaution). The wiki works again!

edit 2008-05-07: typo in the title about the PHP version being upgraded to, it's 5.2.5 not 5.2.25. New release 5.2.6 came out this week.

Wednesday, 07 November 2007

worked it out: unable to import photos from digital camera via USB to fedora 7 system
I ran into this problem and spent an annoying two hours trying to figure it out. I couldn't get the photos off my camera to my Fedora 7 x64 system. The gthumb import dialog gives the error:

"An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device."

Google turned up a few hits but none seemed to give the immediate answer. A few of the hits suggested it was a permissions problem. This is verified via the terminal with 'gphoto2 --list-files' (if you run it as root, you can access the camera fine, but not via the regular user account). However, I didn't want to switch to root just to get photos off my camera, and I wasn't thrilled either to be going back to 2004 with my shell script to do the file transfer.

A few of the Google hits mention futzing with udev. I don't know jack about udev, but sometimes I just can't ignore that devilish mischievousness that cackles at the thought of poking various internal bits of the system, gleefully ignoring the blaring red alarms and risking the health and safety of women and small furry animals. There's a directory of rules for how udev should create device nodes when the system encounters new hardware. A search through /etc/udev/rules.d/50-udev.rules shows the string "usb" in several places, such as this group of lines:
```
# usb devices
KERNEL=="usb/dabusb*",		MODE="0660"
KERNEL=="usb/mdc800*",		MODE="0660"
KERNEL=="usb/rio500",		MODE="0660"
```
However, changing these to mode 0666 does not work. Farther down the file, there is this line:
```
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \
	NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
```
This has a mode also, so I set it to 0666. Instead of exploding on me, the photo import now works. Yay! Now that I have new photos, you may berate me for not updating my photo blog.

P.S. You might be wondering why mode should be "666". There's nothing satanic about it, it's just a throwback to the Unix-style file permissions (read/write/execute for owner,group, and others).

Friday, 05 October 2007

under construction

This is where I put up a cheesy pic of a road construction sign with some stick-figure guy shoveling manure. Site is being redesigned and re-purposed. Photos will still be here, but so will other stuff too.

In other boring news, I read "The Good Earth" earlier this week. This is the sort of book I wished I could have read before I got old.
asdoc and -templates-path

The flex documentation tool, asdoc, would not do anything I asked it to. It would spit out an error message saying "Error: 'templates-path' is not a directory". I couldn't figure out where the heck it was being told to use a templates-path: there's no reference to it in the flex config file, and it's not an environment variable. By luck, I was poking around the help messages ("asdoc -help list") and noticed templates-path is an option to the asdoc tool. A quick look at the adobe asdoc tool reference shows it's the path to the documentation templates it needs to build the documentation, and has a default setting.

Duh.

Of course it needs templates to build the documentation! It was something stupid, like not finding the templates and thus quitting. The solution was to specify it explicitly on the shell: "asdoc -templates-path path to templates other options".