Archive for September, 2005

PEAR Channel Server

September 26th, 2005

I’ve finally finished setting up a PEAR Channel for UNL using Chiara_PEAR_Server.

http://pear.unl.edu/

The process is quite complex, at least with the current state of things. Greg Beaver has built a sample PEAR Server installable using PEAR.

The simple way to set up a PEAR Server using available packages should be:

sudo pear channel-discover pear.chiaraquartet.net
sudo pear install -f –alldeps chiara/Chiara_PEAR_Server
sudo pear run-scripts chiara/Chiara_PEAR_Server

Then answer all the questions and it should create the Database, Tables, Admin user login, and write out a file to your document root.

In fact there is a ‘Tutorial’ out there by Tobias Schlitt that basically states exactly that. But I had some trouble along the way.

Changes:

360d359
< return false;
361a361
> return $a;
381c381
< if (!$this->lastversion) {
---
> //if (!$this->lastversion) {
400c400,401
< $dbo->channel = $answers['name'];
---
> $dbo->channel = $this->channel;
404c405
< $dbo->channel = $answers['name'];
---
> $dbo->channel = $this->channel;
412c413
< }
---
> //}
417a419
> /*
420a423
> */
616,617c619,620
< $phpdir = str_replace('\\', '/', 'C:\php5\pear');
< $datadir = str_replace('\\', '/', 'C:\php5\pear\data');
---
> $phpdir = str_replace('\\', '/', '/usr/local/php5/lib/php');
> $datadir = str_replace('\\', '/', '/usr/local/php5/lib/php/data');

With those fixes, I was finally able to get Chiara_PEAR_Server working.

No comments »

Posted in PEAR

XServe Upgrade to Tiger

September 17th, 2005

Well, we made the plunge yesterday and upgraded our XServe from 10.2.8 to 10.4.2.

The process was fairly painless but we did run into a few glitches. The internal RAID had degraded beyond repair so both drives needed to be rebuilt, which involved moving everything off of the server. Uptimes were important to us (and we did it during the middle of the day)… so we needed to at least try and keep it running as much as possible.
We opted for 2 bootable backups of the server, just in case one went sour. So we used Carbon Copy Cloner to mirror the boot drive onto a firewire LaCie 250GB drive first, and a second backup onto a formatted iPod.
While we were cloning to the iPod I wished we had cloned to the iPod first so the LaCie would have the latest copy to boot from… but since we had the iPod hooked up with the latest clone, we opted to run the XServe off of the iPod.
Through the system preferences we chose the iPod as the Startup Disk, crossed our fingers and rebooted.
To my surprise, the XServe booted FASTER off of the iPod than the internal drives. I think this had something to do with the degraded Raid, but I’m not sure. The Xserve came up and ran off of the iPod while we rebuilt the internal drives.
There was one problem while we were running off the iPod — the name of the boot drive changed to iPod – so even though we had mirrored everything onto the iPod applications that referenced files using VOLUMENAME::DIR1::DIR2 etc were broken. But my PHP web applications which reference the Unix filesystem worked perfectly.

While booted from the iPod, we used SoftRAID to rebuild the drives and create a SoftRAID mirror for the new system… which took no time at all (it was during the ‘initialization’ that all the FileMaker apps broke and lost references to the location of their files).
With the new mirrored drives, we once again used Carbon Copy Cloner to mirror the iPod back to the new SoftRAID mirror (thus restoring the FileMaker apps).

We changed the Startup Disk back to the mirrored internal drives and rebooted with a system on happily mirrored drives.

Now was the part that made me nervous, upgrading to Tiger.
We inserted the Tiger install disk and started the setup which rebooted the machine – unfortunately this left us with a black screen, with no indication of what was wrong.

Confused, we went to the manual for SoftRAID which advises to modify the OSX install disk to add the SoftRAID driver so the bootable CD can see your filesystem. [Crap]
While the SoftRAID docs said the Tiger install DVD includes the SoftRAID driver, we were using CDs to install. So we needed to burn a modified Tiger install disk, but how to get the disk out of the XServe!? By holding down Apple+o+f on boot to enter the open firmware where you can type ‘eject cd’, then ‘mac boot’ to start up the system.
Positive this was the culprit we used a Powerbook to burn the modified Tiger install disk with the SoftRAID driver.

Now that we had a new Tiger Install disk, we attempted to install again but once again were greeted with a black screen. This is when I suggested holding down Apple+v on boot to get more details of what exactly was wrong (I had an old G3 or G4 that I had to hold down Apple+v every time I booted for some reason).
Apple+v somehow helped the server boot up from the install Disk.

The install was fairly painless, and after about 20 min we had an upgraded XServe.

Everything looked like it was running OK, except for the MySQL databases – which didn’t come across in the upgrade. I anticipated this and had made a full backup using MySQL Administrator. I used MySQL Administrator to restore the backup, but unfortunately the latest version (1.1.0) wouldn’t run on 10.4 Server. So I had to use the old version (1.0.22).
The restore process was somewhat difficult, I had a 200MB file I wanted to restore but it stalled out and gave me no indication of what was wrong. This is when I had to resort to the console and redirected the backup .sql file to mysql. This told me that one (or more) of the statements exceeded the maximum size an sql statement can be. I needed to increase the max_allowed_packet in /etc/my.cnf.

[mysqld]
max_allowed_packet = 64M

I restarted the daemon and then MySQL Administrator had no problem restoring the data.

So the databases were now restored, but what about my web applications?

PHP couldn’t connect to the databases through localhost.

PHP connects to databases on the localhost directly through a socket referenced in the filesystem. This was the culprit and fortunately Apple had a document on the exact problem I was having. MySQL creates the socket in a different location than where PHP looks for it.

Unfortunately the doc states that just copying the default php file and changing the socket info will fix it (sudo cp /etc/php.ini.default /etc/php.ini). But the php.ini file on our server was in /usr/local/php/lib/php.ini.

Edited the correct file, restarted the webserver, and everything worked perfectly – except SSL!?

Which is still broken, I guess my Saturday will be taken up fixing the SSL for the webserver.

And that’s how you upgrade your XServe from 10.2.8 to 10.4.2 using an iPod.

No comments »

Posted in Uncategorized