Bugzilla:Mac OS X installation

I installed Bugzilla 2.20 on MacOS X Server 10.4 on 2005-10-24. Here are some notes that might help others:

• GUI apps to manage Apache ("Server Admin") and MySQL ("MySQL Manager"). Pretty straightforward. I figured it would be GUI and used Google on site:apple.com to find the instructions for this.

• CPAN wasn't working for me; something to do with FTP, with an error message I hadn't seen before, something like "OOPS: can't bind to IPv4 socket". This only came up on some FTP sites, but ftp.cpan.org was one of them. Switching passive mode on and off didn't help. I've had CPAN problems on other platforms, and used my usual solution (used CPAN web search to locate module sources, downloaded, unpacked, installed by hand (perl Makefile.PL && make && make test && make install).

• Didn't have "make", to build the CPAN packages. To get it, I installed the optional Developer Tools package from the MacOS X Server 10.4 install DVDs. This needs 1.5 GB of disk space. Seems like a lot just to get GNU make (and gcc, as it happens).

• Didn't have libgd (I know that this is mentioned in the 2.20 Bugzilla Guide, but I had forgotten). Downloaded, built, very smooth.

• Once I had checksetup running, I tried loading the index page and got a MySQL error message, complaining that I couldn't talk to MySQL on the socket /var/mysql/mysql.sock and suggesting I check the localconfig db_user and db_pass.
  This was a nightmare for about two solid hours, during which time I tried a lot of things. I was incidentally reminded that I don't know how to force the MySQL shell client to use TCP/IP sockets (doing what it says in the man page just doesn't work).
  Part of the problem was the Apache GUI config, as that meant I couldn't see and tweak the httpd.conf or the Apache startup script. (for a while I thought that the web server must be running in a jail or similar).
  What it eventually turned out to be was that the MySQL socket /var/mysql/mysql.sock had permissions 770, and the Apache user (www) was not in the necessary group.
  I fixed it (for now) by changing the permissions on the socket to 777.
  On reflection, obviously the right thing would be to put the Apache user in whatever group owns this file (presumably the mysql group). Next time I visit that site I'll change this over.

• Apache out-of-the-box from Apple doesn't kill runaway CGI. I only found this out when the disk filled up with an 21 GB Apache log file generated from a broken script which I wrote to test a hypothesis for point #4. The web browser loading the CGI had long since been closed.