Money has also been tight, so there haven’t been any new trip reports. Nor has there been any new fiction (although it’s not forgotten, just pushed to the back burner). The inquisitive person would say, “Just what the hell have you been doing apart from work?”

Well that’s a pretty good question. When I’m not too stressed with IT to do anything productive, I’ve been working on building my knowledge of PHP and PostgreSQL. More as an exercise in curiosity, but there’s also a practical aspect.

I’ve been a long time user of File Maker Pro, just for some simple databases I use to keep track of geeky things. You know, stuff like mileage and maintenance records for my vehicles, and gang statistics for Necromunda. Not exactly mind taxing work, and it occurred to me one day that I could do the same thing with a free database product and a web front end, thus saving me $100+ whenever File Maker decides to issue an upgrade. I feel compelled to point out that File Maker produces a great product. It’s easy to use, graphically oriented, and most importantly has never lost any of my data in the last 9 years I’ve been using it. However as a casual user who upgrades every two years, that’s about $500 I’ve spent for something that isn’t making me any money.

So I took a look around. There are a multitude of options, but being me I chose some roads less traveled. I decided to go with PostgreSQL simply because it seemed the most generic of the free database products; meaning it more closely follows the SQL standard. So anything I learn there should be reasonably portable.

I also chose to go with PHP as the interface between web and database. Why? Well just because I wanted to learn something new, and it seems to be a pretty popular language for the web. You could argue the merits of using Perl and MySQL, but this is my learning experience. You can use whatever you want when you do it.

So far it’s worked out pretty well. I’ve got my maintenance database up and running, with features I never put into File Maker, and I’m encouraged to move on to other projects (like replacing Quicken, and building my own CMS).

Why would I want to replace Quicken with something of my own? My main gripe is that software vendors are increasingly adopting the position of holding my data hostage. Want to run Quicken on OS XI? Better upgrade. Not to say that Quicken is bad, but after I updated to OS X I’ve been less than impressed with the new features, and it’s been losing my data. It’s my data, and I’ve decided to put it into formats that I can control and more importantly, move around to different systems if I want to.

So where the hell is this going? A couple weeks ago I suffered a hard drive failure on my PowerBook. Not a huge deal, being in the recovery business I make backups of my data. Except, I hadn’t managed to script backing up my database at that point.

The good news is I was able to pull the database files off the damaged drive. Lesson number 1: When implementing a new system, you’d better complete the backup strategy before going production. Mea Culpa. Worst case senario I simply would have lost about a month of data.

Having installed the new drive and reloaded everything else, it was time to get PostgreSQL and PHP working again. That’s what this rambling is all about. It wasn’t a smooth process. I had to spend some time googling some issues to get it all running again. Part of that is my fault, as I decided to update to the latest release of PostgreSQL, Apache2 and PHP.

So here are the web links that helped me, and what I did to build everything out again. Hopefully this will help other OS X users and at the very least, if I need to do it again I’ll have it all written down.

Step One: Install Fink. This is pretty easy to do if you follow the instructions. It makes it easy to load some of the other libraries needed for everything else.

Step Two: Install PostgreSQL. This was also pretty easy. I followed the instructions on Apple’s Developers Site, pretty much to the letter. The only exception is that I opted to install it into the fink area. (/sw) That got the latest code release compiled and running.

Step Three: Update zlib. This is what caused me some problems, but not initially. I installed the version of zlib used in the document in step four. As it turns out this was a problem.

I used PEAR extensively in my project. It seemed like a good idea to abstract the code from the type of database I was using, so in the future I could fairly easily switch if I wanted to.

The problem is that there is a bug in PHP which prevented PEAR from being able to download and install modules and I needed the DB.php module. At first I thought it was a problem in PEAR itself, but after some research it became clear that the version of zlib I had installed. Or more correctly, how I had compile it. It looks like if you compile it as a static binary, PHP has issues.

So I downloaded the latest version from the home site, and then configured it as follows:

./configure --prefix=/usr/local --shared

Not a big change, but it made a big difference to PEAR.

Step Four: Install Apache2. Again, this was pretty easy, following instructions from the PHPMac site. I even followed the directions there for making OS X use apache2 for Web Sharing. This makes it easy to start and stop from the GUI. (Yes I’m quite aware of how to start and stop it from a command line.)

Step Five: Install PHP. I went ahead and followed the instructions on PHPMac again, but with a few really important changes.

I had to modify the configure command with the location of my new zlib, and for use with PostgreSQL:

./configure \
--with-zlib-dir=/usr/local \
--with-libjpeg=/sw  \
--with-libtiff=/sw  \
--with-libpng=/sw  \
--with-gd  \
--with-pgsql=/sw/pg \
--with-xml \
--with-dom \
--with-apxs

Now, I’m not going to guarantee that this will work perfectly for everyone. But it worked for me, and I’m putting this out here to help anyone else who might find themselves in the same position.

My database is once again functional, and I can move on to my other projects for it. However there’s one thing I need to do first:

Implement a scheduled database backup!

Oh yeah. I’m all over that.