Snow Leopard Server-Related Changes

That title should give you a hint just how much my responsibilities have changed since I took my new job. Yes, I still run a Mac OS X Server, but I no longer get bi-yearly hardware updates. So my server is running a PPC, as is my workstation. So no Snow Leopard Server for me, at least not for a while.

I have noticed (as have many others) a few changes to how Snow Leopard handles certain server-related tasks, and I thought I'd just jot them down for the record — mine as much as yours.

Directory Utility

The first, and possibly weirdest, change is that Directory Utility is no longer a readily available application. It now lives in the very unintuitive /System/Library/Core Services, which tells me that Apple would rather us not use it unless absolutely necessary, which, generally speaking, it should not be, at least not for binding to Open Directory servers. Much of its functionality has moved to other applications and parts of the OS.

OD Server Binding

Curiously, OD binding now happens in the Login Options section of the Accounts preference pane. Even more curiously, you can open the Directory Utility from here as well:

Snow Leopard OD Binding

NFS Mounts

Directory Utility used to have a pane for configuring NFS automounts. That pane has been moved to the arguably more logical Disk Utility application, where you access it under File->NFS Mounts, but it looks pretty much the same as it did before:

Snow Leopard NFS Mounts

Root User

Since 10.5 the root user has also been activated via Directory Utility. I haven't found a new way to do this. It looks like if that's your bag you'll need to either find a way to open Directory Utility, or use the command-line. 'Course, if you know what root is, you shouldn't find either of these things terribly difficult. Especially since I just told you two ways to do the first thing.

Directory

There used to be an app called Directory in the Utilities folder, but it too is gone. I'm assuming some of its functionality has been added to Address Book, which now has its very own Accounts preference pane:

Snow Leopard Addressbook Accounts

And I've read that some of its functionality has been moved to the iCal Server Utility app now included with the 10.6 Server Admin Tools:

iCal Server Utility

I've also read that there is some functionality that is completely gone now.

MCX Cache

A fellow SysAdmin has posted his own groovy list of Snow Leopard changes as well. My favorite:

"New command, mcxrefresh, used for refreshing managed preferences on clients"

Hallelujah! I've bitched frequently about Mac OS X Server's overly aggressive cache. Having a way to clear it makes all the difference.

Conclusion

So we have a bit of a shuffling around here, but overall it looks to me like Apple is trying to keep simplifying the OD binding and setup process in Snow Leopard, as they have done with each iteration of Mac OS X. The most obvious features are in obvious places, whereas the more obscure features have been moved to more obscure locations. Most of these changes make sense, too, though dedicated apps for OD setup make sense on some level too. Must everything be another preference pane? In any case, it's just good to know that all the same stuff is there, it's just been moved around a bit.

On a personal note, it's a bit of a bummer to not get to play with Snow Leopard Server. I may never get the chance, actually. It could be long gone by the time we get new hardware, and we just don't rely on Mac OS X Server like we did at my old job. Ah well life goes on.

If anyone has any Snow Leopard Server stories to share, I'd love to hear them in the comments. As far as reportage goes, though, I'm gonna have to sit this one out.

Installing Firefox On the Mac

Alexander Limi, one of the developers of the fine — and my favorite — browser, Firefox, recently issued a challenge that has been heard by many: how to make application installation more sensible for the less technically advanced. What followed — and, to some extent preceded — was an explosion of discussion on the matter.

It really is somewhat amazing that the preferred method for installing a good deal of Mac software — the so-called "Manual Install" — is one that's liable to be confounding to so many users, particularly given that Apple has gone to such great lengths to simplify software installation. And I agree with much of what I've read on at least one point: The problem is the DMG.

"They drag the application to their dock directly.
This creates a link to the file inside the disk image, which means that every time they try starting Firefox, the disk image is unpacked and mounted, and starting of Firefox becomes very slow, which makes it a bad experience."

It's true; I've seen very computer-savvy users constantly launch Firefox directly from a Dock icon that's linked to the item on the disk image. And there are certainly many users to whom you'll never be able to explain exactly what a disk image is, how it works or why it exists. Frankly, as useful as it is to geeks like you and me, it's kind of a crazy concept for anyone who doesn't care about these sorts of things. And I'm of a mind that most users don't and shouldn't.

That said, our options are limited when it comes to installing software. As Limi points out, most apps these days are actually folders (another conceit most users aren't and shouldn't be aware of), and so they must be installed from some sort of container, particularly if they're coming from the Internet. This can be either a ZIP file or, as is generally the way on the Mac, a DMG. Typically, Apple uses a DMG that contains an Installer package for distributing their own software, probably because their stuff is usually not simple drag-and-drop stuff. They've also created a special "internet-enabled" flag for DMGs that, when applied, will be recognized by Safari, which will proceed to open such DMGs and run any installers contained therein. This, at least, gives us a way to accomplish some of Limi's stated goals for the Firefox installer:

  1. Start the Firefox download.
  2. When the download is complete, the disk image will mount automatically (if they were using Safari), and the Firefox installer runs.
  3. The install procedure continues similar to how it happens on Windows.
  4. As the last step of the process, the installer lets you set Firefox as the default browser, and start the application immediately. We have seen users forget that they just installed Firefox if you don’t let them start it at the end of the process, and make that the default choice.

Having some experience with Mac OS X package creation, I decided to see if I could quickly whip something up that met these goals. I believe I have been successful. Here's the installation procedure I've designed:

  1. The user downloads the Firefox Installer from Safari.

  2. Safari Opens the DMG and runs the Installer.

  3. The Installer uses a standard method by default, which requires a minimum of clicks, and installs Firefox in the default location, /Applications.

  4. Upon pressing "Install," the Installer requests authentication.

  5. Before proceeding, the Installer's preflight routine quits Firefox if it is already running (this is not necessary, we do it as a precaution).

  6. The Installer then proceeds with the installation of the app.

  7. When it has finished it will open the containing folder and highlight Firefox.

  8. And then it will launch the app. If this is the first launch, Firefox will ask the user if she wants to set Firefox as the default.

This is the basic install procedure, but some more advanced users will, of course, want to customize the install location of the app. To that end, the installer I've built also contains a "Customize" option.

Clicking this will allow the user to customize the install location of the app by selecting "Other" from the Location pull-down.

And then choosing the location from the resulting menu.

I believe this method offers the best of all possible worlds given the current state of off-the-shelf installation options for Mac OS X. It offers some level of customization for advanced users, while still offering a guided experience for less Mac- or tech-savvy users. And I believe it fulfills most or all of Limi's stated goals for a Firefox installer. There are even numerous things we can do to further customize this guided experience — things like adding graphics and explanatory text, or running additional pre- and post-flight scripts to perform certain behaviors.

And this will work great for most folks who use Safari as well. But for anything beyond this particular scenario — i.e., anyone trying to install apps from browsers other than Safari, which would be anyone who uses the above method, i.e. Firefox users as well as users of any other browsers — we still have a problem. That problem is DMG behavior. The DMG, despite being immensely useful and a perfectly good application and installer container, once downloaded, is easily forgotten. It's behavior and purpose are arcane to most users. They don't know what to do with it and are confused by its presence. And it has nothing to do with anything normal users think of as "Software Installation."

Some developers have rolled their own solutions to some of these problems. But I think the answer really needs to come from Apple in the form of a unified, internet-savvy Installer format. Something that knows where it comes from and what it's supposed to do, and once downloaded, just does it. Something that developers can all use for any kind of installation, even so-called "simple drag-and-drop." Something that just works, dare I say, at least as well as it does on Windows. Preferably better.

Given the level of abstraction of so many concepts in modern operating systems — applications are folders, disk images are files that can represent volumes, Soylent Green is People — I think drag-and-drop installers are bound to be confusing to many users. The guided experience, while a bit of a bummer for very advanced users, should be the preferred method. And I think the best candidate for improving upon that method is ultimately Apple.

One thing that would help the situation immensely, though, is if browser developers made their apps internet-enabled-DMG-aware, like Safari is. This goes a long way towards mitigating the confusion wrought by the ever-confusing, yet — at least at this point in the game — fairly necessary DMG.

Mac OS X 10.5.8 Reduces Drive Space Usage

I'd day this is probably a first in my career. It appears that after installing the Mac OS X 10.5.8 update my drive space requirements have gone down.

Before 10.5.8

Yup, that's right, my System partition now occupies a bit less space than it did prior to the update. I'd first noticed this on my old PowerBook and thought I was going nuts. But after installing the update on my Intel tower as well, the results seem pretty consistent.

After 10.5.8

If this is the sort of thing we can expect in Snow Leopard, you can officially call me excited.

Now about those upgrade disks. Anyone know what's up with them?

Anyone?

UPDATE:

So I just installed three additional updates — Safari 4.0.3, Security Update 2009-004, and the latest GarageBand patch — and my available drive space has increased even more. One commenter has brought up the possibility that these space gains are simply due to swap files being deleted after a reboot. But all these screen shots — including the first one — are taken immediately after a reboot, so I don't think swap files should be a factor. Also, the gains on my PowerBook were significant enough to rule out swap. And now I'm seeing subsequent updates freeing up even more drive space.

After Additional Updates

No, I think something else is going on here. My suspicion is that we're beginning to see some of the sorts of efficiency improvements — like a smaller disk space footprint — that Snow Leopard is supposed to be all about. I suspect that whatever they're doing in Snow Leopard to reduce disk usage is making its way into the latest bunch of updates, and so these updates are actually decreasing the amount of disk space required by the OS.

But this is only a wild guess. For the record, I've got no more evidence than I'm presenting here, and have not been thorough nor the least bit scientific in my approach to this phenomenon, nor do I have time to investigate much beyond these observations.

I think you have to admit, though, if nothing else, it's quite odd to see a consistent increase in drive capacity after multiple system updates. This is not the usual way of things.

A Lack of Focus

I've had an ongoing beef with Leopard since it's inception. The problem is difficult to describe, but I've had a lot more experience with it since the last time I wrote about it, and I think I now have a better idea of what's going on. So I wanted to revisit the issue as we're near the eve of the release of Snow Leopard, and as I feel better equipped to talk about it. Also because it drives me fairly batty.

The problem can best be described like this: An action taken by an application that is in the background can, under certain conditions, cause that application's window(s) to come to the foreground, covering the application that is currently active. Perhaps an example is in order:

  1. I launch Safari.
  2. Before Safari loads completely, I immediately command-tab to the Finder which has a window open.
  3. When Safari finishes loading, the Safari window covers the Finder window.

Finder Obscured: This Shouldn't Be Possible

To rectify this rather odd state of affairs, a quick command-tab to Safari and then back to the Finder does the trick. Not a huge deal most of the time, sure. But let me cite some examples where it becomes a slightly bigger deal. Here's a similar scenario, but now I'm working in TextEdit:

  1. I'm typing in TextEdit.
  2. I launch Safari.
  3. Before it completely loads, I command-tab back to TextEdit and continue typing.
  4. Suddenly, Safari finishes loading and obscures my TextEdit document window; I can no longer see what I'm typing.
  5. To continue working in TextEdit I must command-tab twice as per the previous example.
  6. Moreover, by all appearances but the menubar, Safari is now the active application, which can trick me into thinking I can start typing in Safari. But when I do this I type something — the wrong thing — into my TextEdit document.
  7. And what if I type something like command-a (Select All) and then delete? Now I've just deleted the contents of my TextEdit file — a file I can't even see.

TextEdit Obscured but Active: Where Am I Typing?

That's a potentially destructive scenario I've just described, and I'd pretty much swear that something like that has happened to me in the past, though I admit I did not document it and the circumstances were probably somewhat different.

Beyond the slightly irksome and the potentially destructive, here's one more exceptionally annoying scenario that I encounter on a daily basis:

  1. I log in to my Mac.
  2. Login items begin to launch.
  3. I open a Finder window and begin to manage files.
  4. As login applications finish loading completely, they steal focus from the Finder.
  5. This makes me unable to work on my Mac until all login items have finished loading completely.

I originally thought this was only happening on my slower hardware, but it happens on every computer I use: My old Powerbook, my work G5 and my 8-core Intel home workstation.

As I've said in the past, this is something I would describe as a bug. Background applications should never obscure active applications unless explicitly requested to do so (like when you bring forward a window from another application, which both activates that application but also leaves all windows but the requested one in the distant background). This is my major complaint with Leopard with which I am otherwise very happy. But it's a big complaint. It's a problem that affects me every day, and all day long. It's a huge usability gaffe in my book, and I'm amazed Apple hasn't addressed it already.

For a quality-obsessed company like Apple and an incredibly usable OS like Mac OS X, this lack of focus seems like a huge oversight. And for Apple's detail-obsessed fans this seems like something that would bother a lot of people. But I've only found one lone short thread on the matter in Apple's discussion forums, and one other thread on a very similar (possibly the same) problem. But no answers.

The good news is that Snow Leopard is right around the corner, and Snow Leopard is all about making improvements to the existing system. Snow Leopard is a refinement release. It's all about the details. So I sincerely hope — and if anyone out there can speak to this, please do get in touch — that Leopard's lack of focus is addressed. That would be most excellent.

Portable Home Directories Part 3: Keychain Oddities

Hey, here's a weird one: I finally got my home account back to working order after my experiment with PHDs only to find that iCal couldn't open any of my online calendars. It kept saying the password was missing from Keychain, then refusing to let me add one, saying that the "Keychain could not be found."

Keychain Not Found

The Keychain application also refused to read my keychains. The keychains were there, as they always had been, in ~/Library/Keychains. Keychain.app just refused to see them. Refused to add them — or anything else for that matter — as well. Keychain First Aid reported everything as fine, but the damn things just wouldn't show up.

Suspecting some sort of weird, post-PHD permissions snafu, I copied the Keychain application to my Desktop and then launched it. This seemed to remedy the problem; the keychains became visible in Keychain.app. But upon re-launching iCal, my keychains became inaccessible again.

Mucking around in Keychain.app, everything looked fine. But I wanted to make sure that my "login" keychain was set to be the default. So I selected another keychain I have, right-clicked it and chose "Make keychain 'systemsboy' Default," then did the same to the login keychain, thus resetting it as the default keychain.

Remaking the Default

After doing this I launched iCal and the password complaints were gone; the calendars all loaded properly. Launching Keychain again, however, seemed to break everything. Again! WTF? No matter what I did, Keychain would eventually lose track of my keychains, and this would cause any application that relied on them to screw up. But I did eventually figure it out.

The solution? Well, it's so simple and so idiotic it's hardly worth a post. But here you go: I rebooted.

That's right. A simple reboot and all my troubles were gone.

Remember, kids: reboot, reboot, reboot!