Whoa! Quartz Extreme!

I was trying to make an alias in List mode today, and ran across something I hadn’t seen before in Mac OS X. Has anyone else seen this? I haven’t seen this tip yet, but I’m a couple days behind on everything Jaguar right now. Here’s a way to move around in a Finder window that’s sort of like using the Spacebar in Photoshop to pan around in an image.

I was trying to make an alias in List mode today, and ran across something I hadn’t seen before in Mac OS X. Has anyone else seen this? I haven’t seen this tip yet, but I’m a couple days behind on everything Jaguar right now.

Here’s a way to move around in a Finder window that’s sort of like using the Spacebar in Photoshop to pan around in an image:

  1. Open a Finder window in Icon or List mode (i.e., not Browser mode).
  2. Hold down the Option and Command keys, and click-and-hold anywhere in the window that is empty (any whitespace counts as empty in List mode). You must not actually select anything with your click, or you’ll make an alias in the next step.
  3. Your mouse cursor changes to a grabber hand. Move it around to move the whole window contents around inside the window frame.

I thought this was a pretty cool demonstration of the new features of Quartz Extreme (or at least Jaguar), and actually potentially useful.

Old news? Already posted at Mac OS X Hints? Let me know!

Jaguar Upgrade: Terminal Problem

This is the eighth in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”. This article discusses changes in the Unix shell environment which affect the use of Terminal, among other things.

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

Today’s posting is a little different. Instead of posting about my solution, I’m posting about a problem — with enough details that hopefully we can figure out the answer together. There are changes in the Unix environment which affect the use of Terminal (or the shell in general, in Unix terms). Specifically, I have a number of shell scripts, which I’ve put into my ~/bin directory, which are no longer being found when I try to use them at the command line. They work fine if I give the full path to them, but can no longer be started by their names alone.

There seems to be some differences in the way that tcsh, the default shell for Mac OS X, is initialized, and that seems a likely culprit. When I compare my archived system with the live system, I can see that some apparently interesting files have been moved to a location that seems like it makes them inactive:

Old System: /usr/share/init

  • aliases
  • completions
  • environment
  • login
  • logout
  • rc
  • README
  • tcsh.defaults

New System: /usr/share/tcsh/examples

  • aliases
  • completions
  • environment
  • login
  • logout
  • rc
  • README
  • tcsh.defaults

The files themselves appear to be the same, but they’ve been moved to a location where they may not be activated.

The README file gives clues as to where one should put the login, logout, and rc files to make them active for a user, or for the whole system. But it’s not at all clear what one should do with the aliases, completions, or environment files.

Any suggestions? E-mail me at the address in the sidebar! (And help me test the new Mail.app ;-)

Rant in Favor of Unix

I know that many people, especially the folks clinging to Mac OS 9, are not fond of, or particularly interested in learning to use, the Unix layer of Mac OS X. Unix is not pretty, but it is powerful. It’s baroque, but it’s incredibly well-designed. It’s not intuitive, but once you know it, it’s far faster than the GUI for many tasks.

You may as well get used to it, Unix is a part of your life if you stay with the Mac. If you can get past your initial phobia, and treat it as something exciting to explore, a new thing to learn, an opportunity to be an expert, you will become more powerful than you could possibly imagine (to steal a quotation). Neal Stephenson’s article, In the Beginning was the Command Line, is a fun look at this concept.

Personally, I love the command line, though I wish I was more expert. I get by pretty well, but seek to achieve guru status in the next two years.

A Funny Kind of Sandwich

I was on News.com the other day, and noticed in their Video section an interview with Ken Bereskin, director of marketing for Mac OS X at Apple, talking about Jaguar. There were commercials before and after the video. Guess who was the advertiser.

I was on News.com the other day, and noticed in their Video section an interview with Ken Bereskin, director of marketing for Mac OS X at Apple, talking about Jaguar. Of course I couldn’t resist, and after choosing a video format, I saw David Coursey introduce the clip about to be played. Then there was a commercial, then the six and a half minute segment with David and Ken talking about Mac OS X 10.2, and then another commercial.

The funny — or not so funny — is that both commercials were from Microsoft.

Jaguar Upgrade: Belated Introduction

This is the seventh in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”. This article provides a belated introduction to the series, with a table of contents and summaries of the articles, and an introduction to the author.

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

Series Overview

  • Belated Introduction
    What is this series, who am I, and why am I qualified to tell you anything. (This posting.)
  • Prequel
    Just a short post that I thought served as an introduction, until I re-read it today.
  • Install Options
    Describes the four different upgrade options available from the Jaguar Installation CD, with some details of what they’ll do.
  • What Gets Archived
    Details what files and directories get archived when you use the Archive & Install option to perform a “clean install” upgrade to Jaguar.
  • Post-Install Setup
    There’s a fair amount of work to do after an Archive & Install; this is the first set of things I did, focused on the Mac side of things.
  • Post-Install Unix Stuff, Part I
    There’s work to do on the Unix side, too, if you’re using tools like MySQL and PHP. This post is mostly about fixing MySQL.
  • Post Install Unix Stuff, Part II
    More Unix configuration work, this time for PHP and Apache.

I realized today that I really didn’t provide a good introduction to this series, what the purpose was, etc. So I’m going to pause in the regular postings, and start at the beginning.

I’ve been a Mac user continuously since 1984, and have used virtually every version of Mac OS. My first job was doing end-user computer support for more than 100 Mac users, and I worked there in various roles for more than five years. I’ve even sold Macs, as an Apple Student Rep in college. I’ve also used Windows, mostly Windows 2000. I’ve used Unix quite a bit, mostly since I got into doing web development, and became frustrated with the limitations of Mac OS as a reliable server. And I worked at Be Incorporated for three years, where I fell in love with the idea of an operating system that effectively married a beautiful GUI with a powerful Unix-like subsystem.

So, I’m hardly a typical Mac OS X user, or at least, hardly a typical Mac OS X user who is “switching” from the Classic version to the New version. I love Unix, and I’m not afraid to admit it in public. For me, Mac OS X is a beautiful piece of work. Deeply flawed (file meta-data, anyone?), but still brilliant. I switched from Mac OS 9 to Mac OS X 10.1 shortly after it came out, and I can literally count on my fingers and toes the number of times I’ve booted back into Mac OS 9 proper since then — most of those to run DiskWarrior.

My goal in writing these postings was to start to develop the body of knowledge that I once had for Mac OS Classic. In particular, the “best practice” of doing a clean install when upgrading to a major new release of Mac OS was something I understood extremely well.

But with Mac OS X, the rules have all changed. The core operating system is still stored in a directory named “System”, but that directory is vastly more structured and complicated. And there are dozens of other places where system components and preferences are located, to say nothing of the many more locations where third-party software can be installed.

It’s a brand new world, and while I was sure that doing a clean install was still a best practice, I no longer knew how to perform a clean install, or at least do one efficiently. My Jaguar upgrade was to be my first, and I not only didn’t want to lose a scrap of hard-won knowledge, I wanted to share it with others, and learn from them, so that I could get up the knowledge curve quickly.

So I started these postings. Hopefully they are moderately interesting or useful. This series isn’t supposed to be a review of Jaguar. Everyone else is doing that, much better than I could. This is working knowledge, and I hope you’ll read and learn, and share with me the things you know that I don’t.

Final thought: I don’t talk about it in the articles themselves, but I made a total of four full-system backups before I started. Two of them were stored off-site. Yes, I’m paranoid, but with good reason. Back up your system before you upgrade.

Jaguar Upgrade: Post Install Unix Stuff, Part II

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

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

This posting is a continuation of yesterday’s discussion, covering the post-installation work I had to do to get my most important Unix tools working when I upgraded to Jaguar. Just to recap, here are the tasks I had to work through to get this weblog publishing system working again:

  • 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_

Yesterday covered the first four items, concerning MySQL. Today we’ll look at the last three, covering Apache and PHP issues.

Re-Enable PHP in Apache Configuration File

The web server at the heart of Mac OS X’s “Personal Web Sharing” feature is an Open Source project called Apache. To call Apache “Personal Web Sharing” is something of a misnomer; Apache is truly an industrial-strength web server, and proves it by being the number one web server on the Internet, with more than 63% market share (in August 2002). Apple has made Apache incredibly easy to use for Mac OS X users, but they’ve done it by hiding much of Apache’s power and flexibility. To really take advantage of it, especially to add new “modules” to it, you have to fiddle with Apache’s configuration file, /etc/httpd/httpd.conf.

Apache is the most popular web server, and the most popular add-in, or “module” in Apache parlance, is a powerful web scripting language called PHP. PHP is actually included with Mac OS X by default, but it’s deactivated in the Apache configuration file. PHP is the intelligence, the programming language that this weblog application is written in, so I have to have PHP activated.

Which I had done in Mac OS X 10.1, However, as part of the Archive and Install method of upgrading to Jaguar, the entire contents of the /etc directory was archived, which means the changes to my Apache configuration got deactivated.

For most of my other configuration files which were archived, I simply copied them back into place. But for the Apache httpd.conf file, first I compared my old file with the version that Apple included in Jaguar. There were enough changes, all the way through the file, that I decided I didn’t want to replace the new file. That meant I needed to re-apply the various changes I had made, primarily to activate PHP.

All of this is preamble to what is actually a very simple task, made slightly more difficult by the fact that /etc is an invisible directory, and the fact that /etc/httpd/httpd.conf is owned by root, to protect it from accidental mangling which would prevent Apache from working. Not a big deal if you have BBEdit. Dealing with permissions issues so gracefully, by making a Unix complexity into a Mac OS experience, is what makes BBEdit such a joy to use.

A friend of mine, Joe Lewis, has written instructions for activating PHP in Apache on Mac OS X. He wrote the instructions for version 10.1, but they pretty much hold true in Jaguar. His instructions are thorough and include plenty of screen shots, so my instructions here will be brief.

First I uncommented two lines, fairly early in the file. The lines I needed to uncomment originally looked like this (ellipses means lots of lines between things):

...
#LoadModule php4_module        libexec/httpd/libphp4.so
...
#AddModule mod_php4.c
...

All you need to do is remove the “#” from the beginning of each line.

The second part is to add a couple lines further down in the file. I put them right after the line AddType application/x-tar .tgz, but you could just add them to the bottom of the file. I added this whole block, but only the last two lines matter:

# Enable the use of the PHP4 module (not part of the Apache
# distribution - see http://www.php.net/):
#
AddType application/x-httpd-php .html .htm .php .php3
AddType application/x-httpd-php-source .phps

Note that this will activate PHP parsing in all files that end with any of the four extensions above, which includes regular HTML files. You might not want this, but I certainly do. It lets me use the ubiquitous .html extension for all of my files, static and programmatic. This way, if I change from, say, PHP to JSP, I don’t have to rename all the files on my server.

To make the changes take effect, you need to restart Apache; the simplest way is to go to the Sharing system preference panel, and stop and start Personal Web Sharing.

Restore or Properly Set Up the php.ini Configuration File for PHP

PHP, like a great many Unix tools, has multiple ways to configure it. At the most basic level, there are defaults that are built into the software by the programmer. Then there are “flags” you can configure the software with before you compile it. These can replace the default settings the developer created. You can also “pass in” new settings, via command line options — all that extra gobbledygook you see in those long Unix commands. And then there’s the easiest way to work with normally, the configuration file.

Like Apache, PHP has a configuration file. Unlike Apache on Mac OS X, there’s no default configuration file for the version of PHP which Apple includes in Mac OS X, including Jaguar. (I would imagine the reason is mostly marketing, like the lack of MySQL in Mac OS X client; it makes the Server version more “server-like”.)

And the fact is, most people don’t need this configuration file; the defaults in PHP are all very reasonable, and you’re less likely to need to muck with it than you are with Apache. (Even when I was programming in PHP every day, I needed to fiddle with the Apache configuration file 10 times more often than the PHP configuration file on my Unix server.)

In my case, though, the way I compiled MySQL originally, the “socket” where MySQL was “listening” for connections locally (on the same machine) was different from the PHP default “socket” where PHP would try to talk to MySQL. Basically, PHP had one telephone number for MySQL, and MySQL had changed numbers to a new location. Which meant that by default they couldn’t connect to each other. My php.ini configuration file, located at /usr/lib/local/php.ini, corrected this, but it got archived. So I needed to move it back. This required administrator privileges, which made it easier to do on the command line. In Terminal (this is one line, even if it’s wrapped in your browser):

sudo cp /Previous\ Systems/Previous\ System\ 1/usr/lib/php.ini /usr/lib/php.ini

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 the Archive and Install upgrade more than once.

You will be prompted for your Administrator password, required to perform the operation because /usr/lib is a protected directory.

If for some reason you don’t have an archived php.ini configuration file, but now need one, the normal way to get it would be to download and unarchive the entire PHP source code, and locate the one file you need. Kind of a pain in the ass. In case you’re in that situation, I’ve made available two php.ini files, with my changes applied to move the socket to the right place.

Restore User-Level Configuration Files

Every user on a Mac OS X system (like on many other Unix systems) has a special folder in their home directory. On Mac OS X, that folder is named “Sites”, and everything in it is served up at the URL http://your-server-name/~username/, where “username” is the short login for the user (you can also use http://localhost/~username/ as a shortcut to your server, if your web browser and web server are on the same machine). This is each user’s personal web site (Personal Web Sharing needs to be turned on for anyone to see it).

Mac OS X is set up, out of the box, to allow each user to tweak the behavior of Apache when serving their own site. The very last line of the Mac OS X Apache configuration file does something kind of magic. It’s an “include” command, which is able to read in other files, and Apache treats the commands in those files as if they were in the Apache configuration file itself. But what’s particularly interesting about the command, in the Mac OS X version of the file, is it includes a whole directory. This will read in any and every file in that directory.

The purpose of this is to give each user on the Mac OS X system a mechanism for altering the behavior of Apache when sharing their part of the web site. Each user writes a few Apache configuration commands, and saves them in a file in /etc/httpd/users. Apache reads them in and uses them.

Most people don’t need to do this. It’s far-out enough to be editing the main Apache configuration file! However, for my weblog I needed to change the way Apache treated files slightly, to make the URLs to my blog prettier (and, not coincidentally, more search engine-friendly). But I didn’t want to change the behavior everywhere, just for my site. So I had my custom configuration file, /etc/httpd/users/_username_, which gave Apache the necessary instructions.

You guessed it, another item that got archived during my upgrade. Once again, the command line is the easiest way to fix this. In Terminal (this is one line, even if wrapped in your browser):

sudo cp /Previous\ Systems/Previous\ System\ 1/etc/httpd/users/_username_ /etc/httpd/users

Note: You will need to use your actual username in the command, not the string _username_. You may also 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 the Archive and Install upgrade more than once.

You will be prompted for your Administrator password, required to perform the operation, because /usr/lib is a protected directory.

Wow, that’s a lot of ground in the last couple days! Tomorrow I’ll write up a few last odds and ends about my upgrade process, and do some wrap up.

Hello, MacDevCenter Visitors!

Um, gulp! These little postings have been put on the front page of O’Reilly’s MacDevCenter, one of the premier technical news sites for Mac OS X. I can see the results in my Apache logs as I type this! Hello, MacDevCenter visitors!

O'Reilly network macdevcenter Wow! These little postings have been put on the front page of O’Reilly’s MacDevCenter, one of the premier technical news sites for Mac OS X. I can see the results in my Apache logs as I type this. Gulp!

Hello, MacDevCenter visitors!

Jaguar Upgrade: Post-Install Setup

This is the fourth in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”. This article describes many of the post-installation tasks I went through to get back to full operation.

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

While this may not make sense for other people, I divide the post-installation configuration tasks into two parts: fixing issues with my Unix software, and everything else. This posting covers the everything else, since that’s likely to be more interesting. Tomorrow we’ll cover the Unix side.

Before you read this discussion of the work required after doing an Archive & Install, you should read the excellent article at Macworld, which covers these issues more generally. I’m going to get into the weeds, especially with some of the tasks required to re-enable Unix-based tools like PHP and MySQL, which most people won’t care about.

First, though, a warning about one recommendation given in the Macworld article. In talking about what to copy over from your archived .../Library/Printers folder, they suggest that if you’ve previously installed Faxstf, you should copy over the SmithMicro folder from the archives, and put it into your /Library/Printers directory.

When I did this and subsequently tried to re-add my printers (see below), Print Center would crash about 5 seconds after clicking the Add button. After trying this 5-6 times, three different ways, I finally thought to look in the Console (/Applications/Utilities/Console). Lo and behold, there were error messages from Faxstf trying to access a resource which was no longer where it expected; the Archive & Install process had moved it into the archive. Once I removed the SmithMicro folder from /Library/Printers, I had no further difficulties with Print Center.

So let’s get to the things I needed to update. Although the Preserve Users and Network Settings option preserved the vast majority of my settings, there are a few new or changed things in Jaguar that required resetting some preferences and tools:

  • Turn on appropriate services in the Sharing preference panel
    I had had Personal Web Sharing (Apache) and Remote Login (ssh) turned on in Mac OS X 10.1, and the other services turned off. When I booted into Jaguar, all of my sharing services were turned off. So I turned on Apache and ssh. There’s also new options in the Sharing panel, e.g., Windows file sharing and printer sharing, which you might want to consider enabling.
  • Re-add all printers
    Jaguar includes an entirely new printing subsystem under the hood, as well as updated drivers for a wide range of printers. After the upgrade, I had no printers available, the upgrade had removed them. It took me about 5 minutes to re-create my printer configuration, adding an HP Deskjet and Laserjet using the Print Center application.
  • Re-enable the Scripts menuExtra
    Jaguar apparently disables all installed menuExtras (and most third-party ones are incompatible with Jaguar; hopefully this will be fixed quickly), but re-enabling the Scripts menu, an Apple component which provides menubar access to AppleScripts and other scripts, was fairly simple. Just double-click (or otherwise open) the /Applications/AppleScript/ScriptMenu.menu menuExtra.

Another activity after booting into Mac OS X 10.2 for the first time was to disabled a fair number of third-party software components. I’ve installed a lot of software to make myself more comfortable in Mac OS X, and some of that functionality is now in Mac OS 10.2. I knew or suspected that some of the third-party components would conflict in some way with Jaguar. Among them:

  • Contextual menu items
    These can be found in ~/Library/Contextual Menu Items. To disable the ones I suspected, I created a ~/Library/Contextual Menu Items (Disabled) folder and moved them there. (I love having long file names — that folder name was too long in Mac OS 9!) The ones I disabled were:

    • Bare Bones Open With — there is a new Open With command in Jaguar’s Finder, and I want to see how well it works.
    • Zingg! — another Open With contextual menu that is quite excellent.
  • Login items
    Login items are found in the System Preferences panel of the same name. Disabling login items is as simple as selecting them and clicking the Remove button. I turned off a few items, for different reasons:

    • SuperGetInfoHelper — At least for now, I’m turning off everything for SuperGetInfo, to see how well I like the new functionality in Jaguar. Especially now that it’s been updated for Jaguar, I’m pretty sure I’ll turn it back on, which is easily done in SGI’s own preferences.
    • Transport Monitor and Palm Desktop Background — These two helpers are part of Palm Desktop. At least the Transport Monitor needs the Palm Desktop kernel extensions installed, and I’m not installing any third-party kernel extensions until they’ve been updated and certified for Jaguar.
    • StuffIt Magic Menu — another menuExtra which doesn’t work (yet) in Jaguar. May as well turn it off.
    • VersionTracker Pro — this application scans your hard disk and helps you locate out-of-date software. It’s crashing about 10 seconds into its scanning under Jaguar, so it’s clearly not compatible.
  • Preference panes
    Preference panes can be found in the ~/Library/PreferencePanes directory. I used the same technique for disabling these:

    • ASM — this prefPane gives an error when you try to open it in Jaguar. Additionally, it puts an application menu in the menubar, but menuExtras are currently broken in Jaguar (which sucks).
    • SambaSharing — this is replaced by functionality built into Jaguar, at least for my needs.
    • SharePoints — not replaced, but with the changes to sharing, I’d like to wait for an update.
    • Silk — with changes to graphics and font rendering, it seems like a good item to turn off until an update appears. Plus this was a hack to enable font smoothing in Carbon applications that hadn’t been update to do so. With all the updates coming out for Jaguar, that will soon be a problem of the past.
    • sunShield — this is a firewall configuration tool, and I feel like the new preferences in Jaguar will handle my needs fine.
  • Screen saver modules
    • Flurry — I noticed during the beta for Jaguar that Apple was including one of my favorite third-party screen savers, Flurry, in the base OS. Sure enough, in the final Jaguar GM, Flurry is still being included. While I think this is wonderful, it means I have a Flurry saver in the standard OS installation location, and a second Flurry saver in my ~/Library/Screen Savers directory. I don’t know if this could cause a conflict, but it surely could lead to using an obsolete version. So I removed the copy I had installed in my own Screen Savers folder.

These are the things which I’ve done so far. I’m quite sure I’ll find other things, and will note them down as I fix them. For example, I haven’t touched my Internet Plug-Ins, although that’s deliberate. For now, I’m running with the default set, to see what works out-of-the-box with Jaguar.

Tomorrow we’ll get seriously technical, and talk about what needs to be updated on the Unix side of the fence.

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:

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!

Jaguar Upgrade: What Gets Archived

This is the third in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”. It describes all of the Mac OS X operating system files which are archived when you choose the Archive and Install option from the Jaguar upgrade installer.

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

As described in the previous post, I chose the Archive & Install method of upgrading. This moves a variety of installed system software into an archival location in the /Previous Systems directory. Understanding exactly what gets moved, and some quirks of the archive itself, are useful when you begin your post-installation configuration work.

Here’s what gets archived into /Previous Systems/Previous System X/:

  • Applications/
    This folder archives all of the applications Apple supplies as part of the base Mac OS X install. This does not include the iApps, like iMove, iTunes, and iDVD, and it does not include any of the third-party applications you’ve installed yourself.

    • Utilities/
      Same story here, all of the Apple-supplied base utilities get archived.
  • bin/ [invisible]
    /bin contains most of the system’s default command line tools on BSD Unix. From what I can tell, the entire contents of the /bin directory get archived. I didn’t install any new command line tools here (the correct place for user-installed command line tools under BSD Unix is usually /usr/local/bin), so it’s possible user-installed tools would be left in place.
  • Developer/
    This will only be archived if you installed Apple’s Developer Tools. The old tools are incompatible with Jaguar, so they are completely archived. You must install the new versions of the Developer Tools to restore access.
  • etc/
    This is a symlink (think alias) to /private/etc, also archived. Details below.
  • Library/
    This is your former /Library directory, and it’s where most of the important things for normal users will be archived to, and many items will need to be restored. (I’ll cover restoration in the next post.)
  • mach
    This is a symlink to the mach.sym file (below). It’s essentially junk, you would never normally need to re-use this.
  • mach_kernel
    A semi-critical system file, also never likely to be re-used.
  • mach.sym
    A semi-critical system file, also never likely to be re-used.
  • private/
    This is a critical directory for people who have mucked about with the Unix layer of Mac OS X. The two most important directories are:

    • etc/
      This directory contains many configuration files for Unix applications, including Apache and ssh, configuration files that determine which servers and services will be launched on startup, periodic tasks and maintenance, and the like.
    • var/
      This directory contains many important logs and messages, including mail if you’ve enabled sendmail, as well as some system configuration files used by NetInfo, among many other things.
  • sbin/ [invisible]
    This is another collection of command line Unix tools. These are considered “critical”, as may of these tools are used in the event of system recovery. From what I can tell, all of the tools installed by Mac OS X in /sbin get archived here.
  • System/
    This is the core operating system directory, of which the dominate item is the Library/ sub-directory. This is where all the core system files, such as CoreServices, Classic, various Frameworks, the Java stuff, and a variety of critical OS X system elements are stored. Since this directory is supposed to be off-limits during normal use, there should be little that you’ll need to re-use here. If you have installed kernel extensions (such as drivers for the Griffen iPort, or your SCSI card, etc.), you’ll probably need to re-install them. However, you should definitely check with your vendor to ensure they’re Jaguar-compatible. Nothing will make your Mac OS X system unstable like an incompatible kernel extension.
  • Users/Shared/
    All of your individual Users directories are preserved and saved in the upgraded system, except for the Shared directory, which is archived. This is something you might want to put back into your /Users directory, especially if you’ve put stuff there. Myself, the only thing I found was some AOL Instant Messenger resources, and since I’ve switched to iChat in Jaguar, I have no need for AIM.
  • usr/ [invisible]
    This is a critical Unix directory, and is where you would install most extra Unix tools and applications, if you’ve been installing applications like MySQL or PostgreSQL. There’s also a slew of “secondary” command line tools installed by Mac OS X. And some of your favorite GUI applications may put command line tools that augment their functionality here (BBEdit is one of these).
  • var/
    This is a symlink to the private/var/ directory, described above.

That’s everything that gets archived. Note that three directories, those marked with an [invisible] above, are normally invisible when in use by the system, and are archived invisible also. This makes it hard to get to them, when you’re ready to start doing your post-installation configuration work. It’s highly useful to use a tool like XRay to uncheck the Invisible bit on these archived directories, so you’ll have no difficulty getting to them later.

Tomorrows post: Post-Installation Reconfiguration.

Jaguar Upgrade: Install Options

This is the second in a series of posts I’m writing about my upgrade to Mac OS X 10.2 “Jaguar”. This article describes the four upgrade options available when you begin your installation with the Jaguar CD.

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

As I mentioned in my first post, I choose to do a form of “clean install” for my upgrade. Installation choices are accessed by clicking the Options button once you’ve selected an install destination. The actual choices offered by the installer are:

  1. Upgrade Existing System
    This installs Jaguar over your existing OS; I don’t know what gets overwritten, other than files that are updated, but this should be the lowest-impact install, leaving the most things intact. It is probably the best choice for most people who just want to upgrade and get on with it, i.e., normal users.

    Since I wanted to clean up some of the junk I have installed over the 10 months I’ve had Mac OS X, I didn’t consider this the right option for me. I think this is the wrong option for “power users” who have heavily customized their system, especially if they have tweaked elements inside the /System or /Library directories, because I have no idea what gets overwritten. That said, it seems to have worked well for one of my co-workers.

  2. Archive & Install
    This is the rough equivalent of doing a “Clean Install” in Mac OS 9. In this case, a new top-level directory is created, /Previous Systems, and inside that a folder is created to hold all the archived elements of the current system. The second folder is numbered, e.g., /Previous Systems/Previous System 1/, and one can assume that each Archive & Install will put yet another archived system here.

    Unlike the Clean Install option with Mac OS 9, Archive & Install offers you the opportunity to preserve most of your settings, with a Preserve Users and Network Settings checkbox option, which defaults to unchecked. This option leaves your /Users directory intact, and copies the appropriate system settings for networks, user accounts, and the like, from the archived system to the new system.

    I chose to do the Archive & Install, and to Preserve Users and Network Settings. This is, I believe, the option most power users will want to choose, as it balances the opportunity to clean out cruft with the tediousness of re-installing all of your software, creating user accounts, re-setting preferences, and so on.

  3. Erase & Install
    This option is for doing a completely clean install, i.e., erasing your hard disk (or partition), and re-installing everything from scratch.

    If you’ve been having substantial problems with your Mac OS X configuration which you cannot track down, this option might be for you. It’s by far the most work, though, especially if you’ve been using Mac OS X for a while, and are thoroughly settled in.

Once you’ve chosen your path, it takes 30-45 minutes to copy files, and then the system reboots and asks for the second Jaguar disk. All told, once you’re past this screen you’re about an hour from booting into Jaguar!

My next post in this series will cover exactly what gets archived into the Previous System X folder that is created during the Archive & Install process.

Upgrading to Jaguar

I just spent much of the day upgrading and re-configuring my Mac to run Jaguar, or Mac OS X 10.2, the forthcoming major upgrade to Mac OS X. Indeed, while the upgrade of the OS itself went extremely smoothly, the aftermath kept this blog off the air for nearly 24 hours.

I just spent much of the day upgrading and re-configuring my Mac to run Jaguar, or Mac OS X 10.2, the forthcoming major upgrade to Mac OS X. While the upgrade of the OS itself went extremely smoothly, the aftermath kept this blog off the air for nearly 24 hours.

I chose to do a clean installation, archiving the previous system installation, and re-using the users and network settings. I think that’s probably going to be the most common approach that “power users” use, because we’ve all mucked around with our system, and doing a clean installation is always a good thing to do from time-to-time, even with an OS as solid as Mac OS X has been for me.

The actually installation took less than an hour of effort (mostly waiting), but then the real work began. I’ve hacked up my system quite a bit, installing a plethora of additional software tools and toys. In particular, I use the MySQL database running on my Mac to drive this site, and the MySQL installation got archived by the upgrade process.

I’ll post more about the process I went through (or rather, what the right steps would have been), but for now, I’ll simply say that Jaguar is running smoothly on my system, and the performance boost that the upgrade has brought is quite noticeable and pleasant.