Jaguar Upgrade: Post-Install Unix Stuff, Part I

This is the fifth in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”. This article describes much of the post-installation work I had to do to get working again the many Unix tools and applications I have installed.

This is the fifth in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”.

For my descriptions here I’ve divided my post-installation tasks into Unix configuration changes, and everything else. Yesterday’s post was about everything else, today we dive into Unix. Not everyone’s favorite topic, I know (someday I’ll post a rant in favor of Unix), but if you’ve configured your Apache web server more than a little, you’ll want to read this.

The first thing to realize is that, as described in my third post, the Archive & Install method of upgrading archives your entire /etc and /usr directory hierarchies. Everything from these directories gets archived, in other words, deactivated. At least on my system, this threw a lot of things off. Before we start to fix this, you’ll want to make the archived .../usr folder visible (I recommend Super Get Info or XRay, both great tools). You may as well make the .../bin and .../sbin folders visible, too.

It’s hard to predict what Unix tools different people will have installed on their systems. There are thousands of different, highly useful tools, and plenty of ways to install them, from pre-packaged installers to downloading the source code and compiling and installing it yourself. I won’t try to give you perfectly general instructions for handling all the possibilities. Instead I’ll detail the things I needed to fix on my system, and let you apply the details to your situation as best you can.

This weblog is run in no small measure by my Mac OS X system; to get my publishing system fully operational after my upgrade, I had to:

  • Restore MySQL to working order
  • Change the MySQL user and group IDs back to their original IDs
  • Restore (or rewrite) the Startup Item that starts the MySQL data server at boot time
  • Re-add the MySQL startup flag to my /etc/hostconfig file
  • Re-enable PHP in my Apache configuration file, /etc/httpd/httpd.conf
  • Restore my php.ini PHP configuration file
  • Restore my custom user-level Apache configuration file, /etc/httpd/users/_username_

I’ll cover the first four items today, to get MySQL up and running. Tomorrow we’ll look at the necessary steps to restore PHP to fully-working order. (If you’re in a crashing hurry for PHP, the bullet list above should at least point you in the right direction of the necessary work.)

Restore MySQL

I installed MySQL by downloading the source code and doing the traditional (for Unix heads) configure/make/make install. This put most of MySQL into the /usr/local/mysql directory, including the location for the data files themselves (not a best practice, but I’ll fix that later, and write it up then). This made restoring MySQL simplicity itself, I just needed to move .../usr/local/mysql from the archive back to the live /usr/local directory. For reasons I won’t go into here (there’s funny permissions on some directories, it’s Unix security, it’s complicated), the easiest way to do this was from the command line. In Terminal (this is one line, even if it’s wrapped in your browser):

sudo mv /Previous\ Systems/Previous\ System\ 1/usr/local/mysql /usr/local

Note: you may need to change the name of the second directory to have the right number for your system archive (“1” in the example), if you’ve done this more than once.

You will be prompted for your Administrator password, required to perform the operation, because it overrides privileges on some of the items.

I originally planned to take the opportunity to update my installation of MySQL, by downloading the source and doing the configure/make/make install dance again. Unfortunately, Apple’s new developer tools have made some substantial changes to the compiler, which apparently is causing problems compiling MySQL. At least for me, it broke during the make. Fortunately, the old version remains compatible, so just moving it back into place was enough, for now.

Fix MySQL user and group IDs

For security reasons, on my system MySQL “runs” as another user. When you log into your Mac (or any Unix-based system), you have a user ID, and your permissions and access in the system are constrained by what that ID has been permitted to do. A user with Administrator privileges has broad access (and root has unlimited access), but most users do not. Running MySQL as a separate user named “mysql” is a Unix security best practice.

What you might not know is that under the human-friendly username “mysql” is a computer-friendly ID, which is just a number, in my system’s case, 401. Although I chose to preserve my Users settings across the upgrade, and the mysql user and group did still exist, their underlying IDs had been changed, reset to something under 100. This meant that the MySQL directory, /usr/local/mysql, that I had just restored had incorrect permissions. They were owned by user ID 401, and that user didn’t exist.

Here’s how to tell if you have that problem: You can find the old user and group IDs by doing the following in Terminal:

cd /usr/local/mysql
ls -l

In the resulting list, if you have this problem, you’ll see numbers instead of users and groups for the ownership columns, e.g.:

What it should look like:

drwxr-xr-x  36 root   mysql  1224 Nov 27  2001 bin
drwxr-xr-x   3 mysql  mysql   102 Aug 21 08:25 run
drwx------  10 mysql  mysql   340 Aug 21 08:25 var

What it looks like if the mysql user and group IDs have changed:

drwxr-xr-x  36 root   401    1224 Nov 27  2001 bin
drwxr-xr-x   3 401    401     102 Aug 21 08:25 run
drwx------  10 401    401     340 Aug 21 08:25 var

(Note: My weblog software is screwing up the formatting here; the key point is that where it should say “mysql” in each line, there will be some number instead, and that number is the old user id (first number) and group id (second number) for the mysql user and group.)

The easiest way to fix this was to change the user and group IDs for mysql back to 401 (or whatever your mysql user and group ID is). And fortunately, even though this is a super-tweaky Unix thing, there’s a nice GUI tool to do the task: NetInfo Manager (/Applications/Utilities/NetInfo Manager).

Apple has written an outstanding article about installing MySQL securely, which explains what you need to do better than I can. The difference here is all you need to do is update the user and group IDs, i.e., find the already existing MySQL user and group, and change the ID numbers back to the old numbers.

Rewrite or Restore MySQL Startup Script

OK, now you should be able to start the MySQL data server manually. But I like to have MySQL start when my system does, just like Apache and ssh do. This requires that you add a Startup Item to the /Library/StartupItems folder. I already had one of these, which got archived, so I needed to move it back from the archive to the active location.

Just copying the old file back should be enough to get MySQL starting up on boot, but I noticed that Apple has changed the format for the Apache startup script substantially, adding subroutines that handle Startup, Shutdown, and Restart situations. So I wrote a new version of my MySQL startup script to conform to their convention, which makes the script more flexible, and possibly easier to control from a GUI tool. You can download my version of the Startup Item at the link below (I haven’t added any localization resources, but you could create them for your system, if you’re not using US English).

Restore the MySQL Startup Flag to /etc/hostconfig

If you look at the script for the MySQL Startup Item, you’ll see that it checks for a “flag” in a system configuration file to see if it should really start up MySQL. This is more the Unix way of doing things than a Mac way of doing things, but it is the way Apache is set up, and in setting up MySQL on my system I have tried to conform to the example Apple has created with Apache.

Adding the startup flag to /etc/hostconfig is fairly simple, if you have BBEdit and BBEdit’s command line tool installed. In Terminal:

bbedit /etc/hostconfig

You want to add one line to the file:


I added it just below the line DNSSERVER=-NO-. In fact, I just copy/pasted that line, and then edited it to look like the line above.

When you try to edit the file, BBEdit will tell you that you don’t own the file. Click the Yes button to unlock it. When you try to save the file, you’ll be prompted for your Administrator password. As long as you don’t touch any other lines, this is a very easy, low-risk procedure.

Note that if you don’t have BBEdit, you can still modify the file, using some other text editor, but you’ll have to jump through a few more hoops. Or you could just buy BBEdit. It’s a spectacularly good piece of software.

You should now be able to reboot your system and have MySQL start up automatically. The quick-and-dirty way to verify this is (once again) in the Terminal:

ps waux | grep mysql

Your output should look something like this:

mysql      336   1.1  0.4    14144   2248  ??  S    Wed08AM   4:14.57 /usr/local/mysql/libexec/mysqld
root       318   0.0  0.0     1828      0  ??  S    Wed08AM   0:00.01 sh /usr/local/mysql/bin/safe_mysqld
alderete   765   0.0  0.0        0      0 std  UV+  11:23AM   0:00.00 grep mysql

The key thing you want to see is the first line, which is the actual MySQL data server.

I won’t tell you how to verify that MySQL is completely functional at this point. If you’ve followed me this far, you are probably the type who knows already. If you don’t, there are some very good GUI-based MySQL administrative tools available. Just search VersionTracker for “MySQL”.

Tomorrow it’s on to PHP!