This Will Take a While

To wit: I have a very large folder — about 100GB — full of material that I intend to archive. That folder used to be called “BurnMe.” But I recently changed my archiving approach such that the “BurnMe” moniker seemed inappropriate. So I renamed “BurnMe” to “ArchiveMe.” My hope was that Time Machine would see that, yes, the folder had changed, but that its contents pointed to already existing files on disk, and that those files hadn’t changed and could thus be referenced with a hard link.

Unfortunately, Time Machine isn’t that smart. What it actually did was erase some older backups to make room, and then it indeed recopied the entire 100GB folder with the new name. Apparently, changing even the name of a file’s enclosing folder counts as a change to the file and will trigger a new backup copy to be created.

Deleting a Backup

My solution to this problem, unfortunately, will be to manage my Time Machine data a bit. It is possible to delete previous Time Machine backups by entering into the interface and right-clicking the file or folder you want to delete, then choosing to “Delete All Backups” of the selected file or folder. From now on I will need to be mindful of name changes to large folders, and be sure and delete the previous backups before (or perhaps after, depending on available space) I do so.

In any case, this is not a huge problem, but it is a minor inconvenience in a process that is meant to be almost entirely hands-off.

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 but Active: 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.

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!

Almost Proper
Wanting to get PHDs working, I decided to try doing things a bit more by the book. I set up our NFS Home Account Server as an NFS Reshare and shared it out over AFP. I also set my home accounts up properly in WGM, using the AFP share as my network home, and a local folder as my local one.

But PHD kept incorrectly syncing things, to the point where I’ve actually now lost some data. Seems PHD, when it syncs, is for some reason using the data on the network drive as the master data set. Files I’ve modified before leaving for work have been reverted back to their old versions — the ones on the network — over night. (Which is weird considering the fact that I was logged out.)

I’m sure this works in a perfectly standard environment, with no existing users and no NFS Reshares, when set up from scratch. But I have to say, I could not be more frustrated with PHDs. So I’m giving up for now and setting my home account back to the local drive. Of course, even reverting back to a non-managed, non-PHD, local account is difficult in this case.

Cache Insanity
The reason for this — and one of the things that’s made testing PHDs so difficult in general — is the insane level of caching the server does with regards to PHDs. Caching is so aggressive that, even after disabling PHDs on the server and restarting the client machine, the SyncAgent on the client continues to attempt to sync my homes. If I try to stop it I get an error that says I can’t stop it because I don’t have a PHD. I’m a big fan of irony, but not in my server software, thank you very much.

No Mobile Account

So now the PHD service is incorrectly syncing my local home account with a network home it shouldn’t even see. Thousands of conflicts are occurring. I’m losing data. Though I’ve disabled the service, the settings persist. This is terrible. Horrible. Godawful.

PHD Conflict Resolution: Why?

And there is no sanctioned, GUI way to stop this from happening.

Freedom!
Eventually I was able to stop the errant syncing by running the ever-trusty:
sudo dscacheutil -flushcache

Jesus! What a kludge!

You can imagine how difficult this has made my testing. I can’t be sure that any change I’ve made on the server is actually happening on the client, so it’s impossible to know where this is failing or what I might be doing wrong without starting from scratch every time I make a configuration change. And starting from scratch is pretty damned difficult as well, as the PHD settings are persistent to a fault.

Is That All There Is?
I’m not sure what to do with PHDs at this point. I don’t think they’re useful for our environment, or for any existing users. Testing them is downright painful. And data loss is a real possibility, and not a risk I’m willing to take with other users’ data.

So, after a couple weeks of some very frustrating testing, I’m afraid I’ll have to pass on PHDs. It’s a nice idea, but not ready for prime time from where I sit.

There’s a slight chance I’ll try PHDs from scratch with a fresh home account, just to see if it works at all. But we’ll see. I’m pretty annoyed at this point.

More annoyed than I ever was with Windows Roaming Profiles. And that’s a feat.

After some water-cooler-side conversation, and some excellent comments by my excellent readers, I’ve decided I might be just be a perfect candidate for something that may offer the best of both worlds.

Portable Home Directories

Portable Home Directories (PHDs), as they’re called by Apple, essentially allow a user to keep and work from a local copy of his network home account. The local account is synced up with the network account using various strategies, which I’ll talk about in a bit. It’s essentially an intelligent implementation of Windows’ crappy Roaming Profiles. The big difference is those strategies I mentioned.

Windows’ Roaming Profiles are problematic, particularly in production environments where users store a lot of data, because Windows simply hard syncs those profiles at login and logout. This means that if you’ve generated a lot of data in any given session, you’re in for a long wait when you log out — and another long wait if you log into another machine — while Windows syncs your local and network profiles. It’s a nice idea — giving you the centrality of a network account and the responsiveness of a local one — but it fails in practice because it is, essentially, dumb, causing the sync process to ruin the experience.

The experience we’re going for here is, of course, seamlessness. Or as close to it as possible. So: I want to be able to log in to my workstation and have the responsiveness and normalcy of a local account, but I then want to be able to log in to another workstation and have my documents follow me throughout a given facility. Moreover, I want the synchronization of said documents to be as invisible as possible to the user. It should “just work.” With as little waiting and confusion as possible.

This is, of course, easier said than done.

Apple takes a noble stab at this with its Portable Home Directory settings. See, where Microsoft simply syncs account data at login and logout, Apple affords some granularity in what gets synced and at what times. Apple gives you precise control over what gets synced, as well as allowing for not just login and logout syncing, but periodic syncing as well. Smart! And it could make all the difference.

But I’m getting ahead of myself again. Let’s actually step through the process of creating a Portable Home Account. I’ll show where it shines and where it falls apart for me.

Activate Mobility Preferences

• This all starts in Workgroup Manager. So fire that up and navigate to the user you want on Portable Homes.
• Make sure that user’s current home account is a Network Home Account (i.e., it lives on a server somewhere).
• Click the “Preferences” button from the toolbar, and then open the “Mobility” pane. This is where all the action happens.
  

  Mobility Preferences

Set Account Creation Options

• The first thing to set up is how and when the local portable account is created. Click on the Account Creation tab and set Manage: to Always.
• Since I already have a network home account that I’ve been using from an NFS share (on a non-Apple server), I set my user to “Create mobile account when user logs in” using the “default sync settings.” I assumed this would copy everything over from the network account to the local drive and start the ball rolling fresh, but that’s not what happened. More on that in a bit.
  

  Account Creation

• Under Account Creation’s Options tab I set a custom path that pointed to a folder that contained a local version of my home account that I’d rsynced previously. Again, I did this thinking it would speed the initial sync process, but that turned out to not be the case.
  

  Account Creation Options

Set Sync Rules

• Finally it’s time to define how the syncing between local and network homes will behave. This is the real genius behind the Portable Home Directory system, and what distinguishes it from Roaming Profiles.
• First under the Rules tab you have “Login & Logout Sync.” This allows you to set specific items to sync only at login and logout. The suggested defaults for this are mainly your account settings, i.e. your entire ~/Library folder. This is quite sane, and I stuck with this setting.
  

  Login & Logout Rules

• Note the “Merge with user’s settings” checkbox. I initially checked this, but later found it problematic. It was useful on my first sync, but it doesn’t appear to track deletions and such, so I ended up disabling it.
• Also of note is the “Skip items” section. This allows for what rsync users would call exclusions. This also greatly speeds syncing as you can exclude unneeded items such as cache and trash. I stuck with the sane defaults here as well.
• Next up are your Background Sync settings. Again, very sane defaults are provided: We back up your entire home account, periodically, in the background. Skip the usual suspects and don’t merge.
  

  Background Sync Rules

• Finally, under Options, we can set the frequency with which the server will run the background sync.
  

  Background Frequency

• I also set the option to “Show status in menu bar.” This, as you’ll see, becomes quite useful for the way I ultimately ended up using this feature.

Some Disclaimers
Portable Home Directories are actually not specifically intended for the sort of use-case we’re applying them to here. PHDs are actually designed for users with laptops that come and go onto a network that is also populated with stationary workstations. It’s really made to be used in conjunction with network home accounts, allowing laptop users to use network home accounts without being completely tethered to the network.

So to be clear, this is an experiment. I’m doing things a bit outside the norm. (I mean, what fun would it be if I weren’t.) And any problems I had were likely because of this fact. Still, it’s hinted at in the documentation that PHDs can be used for users of non-portable machines to some advantage, so I wanted to see how we could apply them to our (okay, my) particular situation.

I started off a bit outside the realm of the typical first time setup. I had two things at the outset that essentially represented a test of how we might migrate to a PHD-style system: I had a network home account already populated with data, and I had a copy of that data on a local hard drive. This represents our typical user. But I was also hoping that I’d be able to use these to get the Portable Homes process underway more speedily. This was not the case at all.

Initial Experiences
The first thing that happened when I logged into my newly Portable Homes-activated account was that I was greeted with a prompt asking me if I wanted to create a portable home.

Initial Prompt

I chose to do so (“Yes”), since that was pretty much what I was here to do. And upon login I was greeted, not with my previously set up network home account nor my rsynced local account, but rather with the standard boilerplate skel account you see when creating a new user. Worse, the server seemed to get confused as to where my home account should be placed on the local drive. Though I had defined it on my server as a custom path, it seemed to want to go in a folder called “User” on the specified drive, no matter what I entered for the custom path. Apparently, for me anyway, the custom path — and my hopes of speeding the sync process — just plain old didn’t work.

Default Login Environment: Not What I was Hoping For

After this I decided to try again. I moved my custom folder off the local drive and, in Mobility Preferences, simply defined the drive I wanted to use for my Portable Home. I also chose to “Merge with user’s settings” for this go ’round under the Rules section of the Mobility prefs. The thought was that this should pull down my network home account and create a local version from it. And this is exactly what happened. And for a time life was good and I thought I was done. I thought I’d found my magic settings. But the next day I logged in to find that once again my account had reverted back to the default, first-login settings. Yikes!

Portable Homes Weirdness

(Here I’d just like to point out the benefits of having a backup of your entire home account if you’re going to play around with this. Or just use a spare, dummy account. I actually did lose data numerous times during my testing, as you’ll see in Part 2.)

After poking around a bit I discovered that my machine had logged me into my network home. Or at least that’s where the Finder went when I hit Command-Shift-H. But my home account settings were the defaults, not my network home account settings. WTF? Logging out and logging back in I found myself in what I considered to be the right local location, and all my custom settings had returned. But this was clearly getting weird and flaky. And no matter how I configured things, the weirdness persisted. The biggest problem, though, was the fact that my local and network home accounts never synced in the background. And that was sort of the most important part.

Manual Sync
For a time I used Portable Home Directories the only way I could get it to work for me. Remember that tickbox to “Show status in menu bar?” Well, it turns out that you can use this menubar widget to manually sync your local and network home accounts. And manual syncing actually worked okay for me. In fact, it was the only way I could get my network and local data in sync.

Menubar Icon

During this time I pretty much using the default Mobility settings, but my account was on my Work drive. Portable Homes had placed it at:
/Volumes/Work/systemsboy.xahomes
for some strange reason, but I could live with that. Every so often — particularly if I thought I might be going to another machine and logging in as myself — I’d hit “Sync Home Now” in the Menubar pulldown.

Sync Home Now

This would begin the Home Sync process. The process is far from immediate, but it’s not too slow. It takes a few minutes. Once it’s done I can verify that my network and local homes are synced up.

Home Sync Status

Conflicts that the service couldn’t resolve were handled similarly to iPhone-to-AddressBook conflicts, though, with the usual PHD flakiness: often conflicts occurred where they shouldn’t have.

PHD Conflict Resolution

But the biggest problem with Manual Sync was that logging in to another computer failed. A popup alert appeared telling me I was unable to log in at this time because “an error occurred.” Great.

I was really hoping for this to be seamless, of course. But it just may not be possible with this particular setup. The best I can get out of Portable Homes so far is not much better than a glorified rsync script with a pretty GUI for running it and some semblance of conflict resolution. And it completely breaks my ability to log into other computers.

Conclusion (For Now)
In the end I decided that my troubles were likely due to the fact that I was not working in the typical Mac OS X idiom. It’s my guess that Portable Homes failed for me in this instance mainly because my network home account is on a completely different, non-Apple server, one that my Mac Server is not set up to share as a network home location. I would venture that if you set Portable Homes up just like it says in the manual, using Apple kit and AFP and the like (possibly AFP reshares would work), Portable Homes works like a charm. But if you don’t you’ll get some strangeness like I did. Ah, the joys of the bleeding edge!

On my first shot at Portable Homes I experienced a number of surprises and inconsistencies. While Portable Homes is a great idea, and in theory looks to be perfect for someone like me, there are major pitfalls in a complex, multi-platform environment that prevent it from being usable for much of anything. But Portable Homes has potential and I plan to delve more into how to get it working for us in our complex environment. In our next installment I’ll be trying a setup more closely aligned with the Apple-sanctioned method for implementing PHDs. We’ll see how it goes.

1. Activate the service in Server Admin.
   

   Activate Software Update Service

2. Configure the service. I like to configure the SU Server to “Automatically copy all new updates from Apple.” This is the easiest, and I like things easy. But otherwise I use the default settings.
   

   Configure General Options

3. Start the service and list the updates. And here’s one of the gotchas: when you first start the service there is no indication that anything is happening. There is no progress bar and nothing will appear in the list of updates. But in fact the SU Server is downloading all the updates (several Gigs) in the background. The easiest way to prove that this is actually happening is to run the df command, then run it again. You should see your root drive getting gradually fuller as the server downloads the updates. This first download will take a long time. I like to let it go overnight.
   

   Updates

4. When you return the next morning, the list should be populated with all the available updates, as seen above. (Also, you see about 10-15 GBs of data in the Software Update Server’s data store, which is here: /usr/share/swupd/html/content/downloads/.) The last step then — and the thing I often forget — is to tell your client Macs where to get their Software Updates. To do this you’ll need a computer list in Workgroup Manager. Add any computers you want to use your SU Server to the list. Then go to the Preferences pane for the group and select Software Update. Set the URL for the SU Server to: http://server.domain.com:8088/index.sucatalog
   

   Create Computer Group

5. After saving that configuration, logging out and logging back in should be all you need to do on your clients to pick up the server. After doing so, run Software Update and you’ll see the name of your SU Server in the menubar of the interface. This confirms you’re successfully getting updates from the server.
   

   It Works!

Congrats! You’re not a total moron. Enjoy!

UPDATE:
Reader Dennis points out in the comments that individual clients can be configured to look to the SUServer for updates without being part of a WGM group or managed by the server at all. This is done by modifying a preference on the client system, which you would do thusly:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL "http://systemsboy.su.server.com:8088/"

That command can, of course, be sent en masses using Apple Remote Desktop’s “Send Unix Command” directive.

And, if you want to revert to the standard method of checking for updates, looking at Apple’s servers, delete the “CatalogURL” entry in the preference file by running:

sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL

Thanks for the tip, Dennis!

• Hit the Exposé key (which is F3 on my nifty metal keyboard).
• Hit the tab key. This will tab to the next application and display it as though it were in Exposé’s application window mode, showing all the app’s open windows.
  

  Exposé Tab Selection (click for larger view)

• Continue hitting tab to bring subsequent apps to the front.
• Hit the tilde key to cycle backwards through apps.
• Hit the Return or Enter key to activate the selected app.

This is pretty cool. Who knows, maybe it’ll even encourage me to start using Exposé.

Maybe.

There used to be a time when I would customize the hell out of my Mac. After installing all my apps I’d get to setting up my user account, tricking out all my apps so that they behaved just like I liked, and installing and configuring any number of productivity utilities to make my life easier. It took forever, and it was a huge pain, but once it was done I could navigate my computer quickly and effortlessly.

Those days are pretty much over at this point. I no longer do much to change the default configuration of my home account in any meaningful way. I barely customize the Dock. I may change the Desktop background. On my primary computers I can’t live without a pasteboard history, so on those machines I’ll install the excellent(!) PTHPasteboard. And there are certain Terminal settings I really enjoy. But that’s about it. I don’t even install my beloved Butler anymore.

Too Many Computers!

There are certain things that have contributed to this. For one, Leopard’s Spotlight is a great application launcher, largely mitigating the need for Butler. (Yes, there are other things that Butler does that I miss, but I can live without most of them — but application launching is a deal-breaker.) Spaces helps a lot with window management, so I don’t need the sort of hot corner stuff I used to do. And the newer Mac keyboards have iTunes control built in.

But the main reason for this change (or lack thereof) is the plain fact that I’m simply touching too many computers in the course of the day to ever really consistently customize them. And if it’s not consistent, it’s not going to be very efficient, because every time you go to a different computer your system breaks. I was getting to the point where I’d go to one of the many computers I have to access on a regular basis — a staff member’s machine, or some workstation somewhere — and I’d start frantically hitting the keys for some custom key-command I’d set at home, getting frustrated when nothing happened. At some point I realized that this inconsistency was actually hurting my productivity. So I made the conscious decision to learn a new way.

Lockdown!

Over the past year or so I’ve gotten used to working with the system in as out-of-the-box a configuration as possible. Which ain’t half bad, I have to say. Apple has really done a fine job of making the initial user experience good for both new and experienced users alike. It’s quite remarkable. And I love not having to set much up beyond installing my apps. It’s akin to how I felt when I gave up my car to move to Manhattan. You think you’ll miss it, but you end up realizing what a burden it actually was. It’s kind of great to have everything I need on any newly installed Mac. And now that I don’t rely on that other stuff, I don’t miss it at all.

I know as “power users” we like to add to and configure our machines out the wazoo, and I’ve certainly been no exception. But as a SysAdmin, I have to say, the less of this I do, the better my user experience has been. Surprising, yes. But totally true.

Leopard Quarantine: Yes, I Am Sure, Thank You Very Much

Some have hailed this as a breakthrough in security standards, I’m sure, though I can’t find any specific sources to cite. Most folks who notice such things are actually rather annoyed by the alerts, likening them to similar attempts at security in versions of Windows. Indeed, it’s difficult to make the argument that such a warning would be very effective at preventing user-initiated security breaches. In reality it’s just the sort of warning that most people click through because 99% of the time it’s unwarranted. This has most SysAdmins and advanced users asking, “Why bother?” After which they promptly ask themselves, “How do I turn this shit off?”

The bad news is that there doesn’t seem to be a GUI way. There is no simple System Preferences checkbox for the alert. The good news is that there appears to be at least a couple possibilities for getting this done.

The first approach involves watching whatever folder you use for downloads, either via a Folder Action or via a Launch Daemon. The basic gist is that anytime that folder gets modified a script runs that removes the flag that causes the warning to appear from all items in the downloads folder. Because, you see, that’s all that’s going on. Anytime something is downloaded to your computer, Leopard flags it. When you open it in the Finder, the flag triggers the alert. Confirmation of the alert removes the flag. That’s the mechanism. Using the watch folder method simply disables the flag, which is akin to hitting that “Open” button in the alert, only it happens automatically in the background.

There are a couple problems with this method. First off, it’s difficult to implement, and second, it breaks anytime you decide to start using a different folder for downloads. And then there’s the obvious fact that it’s just plain ugly: a script workaround to disable an OS feature? Bluglgh! Terrible!

A better solution would be some sort of preference file. Apple often enables — but hides from the GUI — certain advanced preferences, allowing more savvy users to set the preference either by the addition of a preference (.plist) file, or by using the defaults command. There are all sorts of mods for the Dock, for instance, that, while unavailable through the GUI can be set via defaults. It appears that Apple has provided such an invisible preference for the Leopard download alert as well. And if you know how to create and edit a .plist file, activating the preference and disabling the alerts is fairly straightforward.

Some Background
The instructions I’m about to provide have been posted in numerous other spots on the Web. But when I went searching for this info there seemed to be no single place that explained not just how to perform the modification, but also what it did and how the mechanism we’re defeating works in the first place. So I wanted to provide some background info about just exactly what’s going on here.

Metadata
The first piece of this puzzle is the basic concept of metadata. Metadata is often best described simply as “data about data.” And in Leopard we (or, more particularly, developers) finally have the ability to add arbitrary metadata. That is, as a developer, you can add any sort of descriptive data you want to your files and the files your application creates. Mac OS X 10.5 and up can read that metadata, interpret it and behave accordingly. So, to follow our example, when we download Camino from the Internet, the Mac OS (specifically, the Finder) adds some metadata to our Camino application, and that metada says, “This application was downloaded from the internet and has not been flagged for approval.” Now, when we go to open the application for the first time, the Mac OS also knows to behave a certain way based on this metadata, and so we see that alert pop up. Clicking the “Open” button writes new metadata to the file, and that metadata now says, “This application has been opened and flagged for approval.” The OS now knows not to present the alert the next time the app is opened. Such is the power of metadata.

By the way, I should mention that you can actually tell which files have metadata associated with them by doing a long file listing:

DrMac:~systemsboy$ ls -l Movies
drwxr-xr-x   9 systemsboy  staff        264 Nov 14 09:35 .
drwxr-xr-x  10 systemsboy  staff        296 Nov  7 17:20 ..
-rw-r--r--@  1 systemsboy  staff  407041761 Oct 31 15:45 DownloadedMovie.mov
-rw-r--r--   1 systemsboy  staff  407041761 Oct 31 15:45 LocalMovie.mov

Notice the “@” symbol at the end of the permissions info for the DownloadedMovie.mov file? That means that this file has metadata associated with it.

You can look at any metadata your files contain by way of the xattr command. The command is simple to use:

DrMac:~systemsboy$ xattr -l Movies/DownloadedMovie.mov
Movies/DownloadedMovie.mov: com.apple.quarantine: 0000;48fa188d;Firefox.app;|org.mozilla.firefox

Here we can see that our DownloadedMovie.mov has an Apple-branded quarantine flag, and that it was downloaded with Firefox. Nice!

UTIs
The next piece of the puzzle comes in the form of something called Universal Type Identifiers, or UTIs. UTIs are a specific kind of metadata that are meant to describe and define types of files. So, our Camino application has metadata not only that tells the OS that it came from the Big Bad Internet (BBI), but also what sort of file (or in this case bundle) it is, namely that it’s an application. This particular piece of metadata is the UTI, and there are a bunch of them. The complete list can be found on Apple’s Developer site. UTIs can be extremely useful, and they’ll actually allow us some flexibility in defeating Apple’s quarantine mechanism. Because with UTIs we can specify which sorts of files trigger the alert and which don’t, which is pretty great if you need it. And even if you don’t, it’s something that might come in handy down the line.

The Defeat
So, with that out of the way, let’s step through our method for disabling the Mac OS alert for downloaded files.

1. The first thing we’ll need is a file in our Preferences folder called “com.apple.DownloadAssessment.plist.” If you have one, great, if not make one, either with Property List Editor, TextEdit or whatever text editor you have handy.
2. Next, populate the file with this data:

    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
      "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
     <dict>
       <key>LSRiskCategoryNeutral</key>
       <dict>
         <key>LSRiskCategoryContentTypes</key>
         <array>
           <string>public.item</string>
         </array>
       </dict>
     </dict>
   </plist>

3. Finally, restart the Finder.

From here on out, the OS will flag any item downloaded from the BBI (the UTI “public.item”) as “Neutral.” This should completely eliminate any sort of alert regarding downloads. Of course, there are exceptions — and I’ll talk about them in a minute — but this should mostly do the trick.

Using UTIs and the Risk Categories outlined here, you can vary and specify the OS behavior for a wide range of file types. Want downloaded applications to raise the alert, but HTML files to be considered safe? Not a problem. Just specify as much in the plist file. It might look something like this:

 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
   "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>LSRiskCategoryUnsafeExecutable</key>
    <dict>
      <key>LSRiskCategoryContentTypes</key>
      <array>
        <string>public.executable</string>
      </array>
    </dict>
  </dict>
  <dict>
    <key>LSRiskCategory</key>
    <dict>
      <key>LSRiskCategoryContentTypes</key>
      <array>
        <string>public.html</string>
      </array>
    </dict>
  </dict>
</plist>

Now, applications we’ve downloaded from the Internet (UTI “public.executable”) will be treated as “Unsafe Executables” and will prompt the quarantine alert. But downloaded HTML files (UTI “public.html”) will be treated as “Safe” and be exempt from the alert. As you can probably gather, you could get really, really fine-grained here if you needed to. Most folks will be covered with the first example, but as a SysAdmin it’s always good to know you have options.

Exceptions
Now earlier I mentioned exceptions. And one of those exceptions is Camino itself. Remember earlier when I specified that developers could add metadata to files? It’s important to understand that it’s not always the Finder or even the Mac OS itself that’s creating this metadata. Applications themselves can also write metadata to files, and that’s exactly what Camino does. Anytime you download a file with Camino it adds it’s own metadata to the download. And that metadata will trigger the Mac OS’s quarantine alert. So the above hack fails for applications such as these, and there’s not much to be done about it. The rationale for Camino’s approach is at least partially detailed in bug report 464333 on Camino’s developer site.

UPDATE: The folks at Camino are now re-examining the issue.

Further Reading
Credit where due, I collected all my info on this topic from the following sources:
The Folder Action Hack
Arbitrarily Extensible Metadata
Uniform Type Identifiers (UTIs)
Download Security Assessments
Creating and/or Modifying the Preference File

And inspiration and help for this post came from an excellent bunch of comments in another article right here on this very site.

In Conclusion
I have to admit, I find what Apple is doing here fascinating. I’m not sure that popup alerts for every downloaded file is a great idea in practice, but I do think it’s an interesting example of what’s possible with metadata and highlights just how useful this addition to the OS could be if leveraged properly. Imagine if metadata were something in the hands of everyday users. Imagine if you could assign your own set of actions based on your own set of metadata tags. It could fundamentally change the way you interact with your computer, essentially allowing you to program it at will to your whims. And maybe someday it will, if Apple sees the potential here and continues to push forward with this Great Metadata Experiment in fresh and innovative ways.

Generally I’m setting up secondary DNS for internal networks, and generally those internal DNS servers  serve DNS only for the internal networks. Everything outside the internal network is handled by external DNS servers (or by DNS servers that sit on a network of which we are a subdomain), and our internal DNS servers need to know who those server are. These external servers are called forwarders, in DNS parlance. They are the first stop for all DNS outside your local network. And you can now set them on your secondary DNS server in the Leopard Server Admin application.

Leopard's Forwarders Pane

To get to the settings, navigate to the “Settings” tab under the DNS service. In the bottom-most pane of the window you will see a box labeled “Forwarder IP Addresses:” Click the plus sign to add a server to the list, then type in an IP address. Typically you will add two addresses, one for the primary external DNS server and one for the secondary. These will often be your ISP’s DNS servers, though if you’re on a subdomain of a larger network you’ll use the DNS servers for that network’s domain (i.e. the subdomain systemsboy.com.mail will use the DNS servers for the domain systemsboy.com). Once you’ve entered and saved the settings, restart your DNS service and you’re off to the races.

Requests for internal network resources will still be handled by your internal DNS server, but now external requests for things like “google.com” will be passed to the appropriate external DNS server. Even if your secondary has to take over DNS duties for a long period of time, you’ll still be able to properly reach the Big Bad Internet without having to use cached or stale settings.

This is a very handy addition to the DNS configuration GUI in Server Admin.