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/hostconfigfile - 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:
MYSQLSERVER=-YES-
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!