Today I set out to write a small utility in Ruby and quickly realized that, while I’ve been off learning Drupal, my Ruby install on the Mac has atrophied. I was foolish enough to allow myself to upgrade to Mac OS 10.5 a mere three weeks after it was released. Normally I wait a couple of months for something like this, until the bugs shake out, but I just had to take advantage of Micro Center’s $40 Leopard rebate, and I couldn’t just leave those disks sitting there…

The good news is that after a single day of struggle upgrading various things, Leopard seems to be working fine for me. In fact, it worked so well with my old Ruby, Rails and MySQL installations (which I had installed in /usr/local per Dan Benjamin’s advice) that it’s only now that I noticed that all my Ruby gems are way out of date. Upgrading the gems in place produced some mysterious errors, so I decided it was time to embrace the future and migrate to the built-in Ruby and Rails support in Leopard. After backing up and killing my MySQL server, I decided to go for broke and just remove and recreate my entire /usr/local directory:

$ sudo mv /usr/local /usr/local_old
$ sudo mkdir /usr/local
$ cd /usr/local
$ sudo mkdir bin doc etc info li man sbin share src

I’m not sure which, if any, of those /usr/local subdirectories I’ll need, but I made ‘em all anyway. Then I rebooted, to make sure that all traces of my former /usr/local were removed from the process list.

Mac OS 10.5 comes complete with its very own well-tailored Ruby and Rubygems install which I’ve decided to use for a while. (Other people seem to prefer using Macports to reinstall these, but I’ll avoid that until I need it.) I’ve already installed the Xtools package for 10.5, so I just updated the existing Rubygems install, following instructions: $ sudo gem update —system

Then I updated the gems that came installed with Leopard:

$ sudo gem update

I had to run this several times, as gems.rubyforge.org returned 404 errors now and then. I guess it’s really busy over there — the Ruby traffic situation is as bad as the Drupal.org situation.

This update just happened to pull down the latest 2.0 release of Rails. I don’t yet know much about this, but I have the docs to read when I get the chance. Then it was time to sudo gem install a few more goodies:

• BlueCloth and rubypants, to make HTML prettier

• newgem, which makes it really easy to initiate new Ruby projects, package them up as gems, and ship them around. This is what I was looking to use this morning.

• sudo gem install deprec --include-dependencies — Deprec is an amazingly useful utility for installing entire Ubuntu-based Rails stacks on remote VPS servers. It’s getting a bit stale (it depends on an old version of Capistrano) but I think it may still be useful.

• rspec, ZenTest, and redgreen : Behavior-Driven Development and automated testing extensions for Ruby. Good, good, good.

Now I need to replace some other stuff that I accidentally blew away along with my entire /usr/local. One of the most important things to reinstall is git. I followed the instructions from this handy blog entry, which paralleled those in the excellent git screencast from Peepcode.

Finally, it’s time to follow Dan Benjamin’s MySQL install instructions. Again, I could be using MacPorts instead, but I’m trying to avoid that for now.

UPDATE: I stopped this post a bit too soon: There was a bit of trouble on the MySQL install:

$ sudo ./bin/mysql_install_db --user=_mysql
Installing MySQL system tables...
071213 14:40:44 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/var/ is case insensitive
ERROR: 1004  Can't create file '/var/folders/aX/aXYUzZmoHruKTlzkbVLQdU+++TM/-Tmp-/#sql10aac_1_0.frm' (errno: 13)
071213 14:40:44 [ERROR] Aborting

071213 14:40:44 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete

Installation of system tables failed!

Looks like it can’t create some weirdly-named file in /var. Now what?

Time to apply the Fundamental Theorem of Unix: When something goes wrong in Unix, it’s a permissions problem.

$ ls -la /var/folders/aX/aXYUzZmoHruKTlzkbVLQdU+++TM/-Tmp-/
total 0
drwx------  5 mike  mike  170 Dec 13 13:29 .
drwxr-xr-x  5 mike  mike  170 Dec 13 10:59 ..
prw-------  1 mike  mike    0 Dec 13 13:24 com.apple.notify.18872.4
prw-------  1 mike  mike    0 Dec 13 13:24 com.apple.notify.18872.5
prw-------  1 mike  mike    0 Dec 13 13:27 com.apple.notify.18872.6

$ chmod 777 /var/folders/aX/aXYUzZmoHruKTlzkbVLQdU+++TM/-Tmp-/

$ sudo ./bin/mysql_install_db --user=mysql
Installing MySQL system tables...
071213 14:42:17 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/var/ is case insensitive
OK
Filling help tables...
071213 14:42:17 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/var/ is case insensitive
OK

$ chmod 700 /var/folders/aX/aXYUzZmoHruKTlzkbVLQdU+++TM/-Tmp-/

On to the next bug…

UPDATE TWO: There’s a better way to solve my permissions problem:

$ cd /usr/local/mysql
$ sudo mkdir tmp
$ sudo chown _mysql:wheel tmp
$ sudo chmod 755 tmp

Then use sudo and your editor of choice to edit /etc/my.cnf and type this into it:

[mysqld]
tmpdir=/usr/local/mysql/tmp

Now when you start mysqld the mysterious permissions problem is gone. This solution is more likely to prevent mysterious and subtle recurrences of the problem.

UPDATE THREE: I wasn’t kidding about “the next bug”. Here it is:

$ mysql -u root
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

This is on my brand new MySQL installation, where I haven’t set a single password yet. I can’t even log in to set those passwords.

I fiddled around with various password options for what seemed like forever. I started mysqld with the --skip-grant-tables option and tried to change the passwords that way. I uninstalled and reinstalled MySQL a couple of times. I entertained happy thoughts of just switching to PostgreSQL.

Then it occurred to me that the problem was my hostname. Maybe the mysql_install_db script that sets up the initial grant tables was picking up the wrong hostname.

$ grep hostname /usr/local/mysql/bin/mysql_install_db
hostname=`/bin/hostname`
 ...

$ /bin/hostname
foo.example.com

Aha, that was it. So let’s try this:

$ mysql -u root -h foo.example.com
ERROR 1130 (00000): Host 'foo.example.com' is not allowed to connect to this MySQL server

Grumble grumble I hate MySQL grumble.

So I uninstall and reinstall again, only this time before running mysql_install_db I edit the line which says

hostname=`/bin/hostname`

and change it to

hostname='localhost'

Lo and behold, now everything seems to be working.