Of Intellectual Interest Only

I had the oddest thing happen to me recently. I was changing my Desktop picture, and I navigated to one of the fuller image folders in the Desktop pane of the System Preferences, and as the images loaded I saw a progress bar at the bottom of the window. I'd never seen this before.

I decided to grab a screen capture of this phenomenon for possible posting here on the blog. Navigating away from the pane and then selecting it again, however, no progress bar appeared. Clearly there was cache afoot.

The cache file that governs when and how long you'll see this progress bar is:

~/Library/Caches/Desktop/NameOfFolder_STRING.dpCache

Where "NameOfFolder" is the name of the folder in Desktop prefs that contains all those images you're trying to look at.

Quitting the System Preferences app, deleting this file, then reopening the Desktop preference pane and selecting the image laden folder reactivated the progress bar and allowed me, at last, to snap this:

Desktop Prefs Pregress Bar

An odd aside: the progress bar appears to actually be a separate window, or possibly a sheet, as evidenced by the fact that using command-shift-4-hover-spacebar-click (wherein only the desired window is grabbed by the screen capture utility, and, not coincidentally, my usual method of screen cap) to make the screen grab produced the following image:

dt-prefs-progress-window-sheet

So maybe you're asking yourself: Is any of this useful information? Um, no. Not really. It's purely academic.

And yet I find it fascinating.

Portable Home Directories Part 2: Oh God, Make it Stop

Last week I began testing the Apple Portable Home Directories feature. I'd heard a lot of good buzz, but my experience was pretty terrible. Of course I was doing things my own way, and not the Apple way, which is always a bit dicey.

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

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.

Snow Leopard Preview

I don't generally post rumors or speculation on upcoming software, but latest Snow Leopard action has me feeling all tingly with anticipation. For a release that was supposed to be mainly about size and performance enhancements and less about new features, Snow Leopard looks to have a bunch of new features that appeal quite a bit to me personally.

Snow Leopard

AppleInsider gives us a preview of what's expected. Among the features that I find particularly useful:

  • Date and Time Prefs now allow you to display the date and/or day of the week in the menubar along with the time without using a hack. (Finally! Jesus!)
  • AddressBook can sync with Google contacts. Actually, it can do this now. Looks like they just revamped the preferences pane a bit. Thanks to JT for catching the error.
  • Scanner Sharing. (Seriously, I'll probably use this.) Scanner sharing is available in Image Capture. They're just putting it in the System Preferences now and treating it like Printer Sharing, it appears. Thanks, P-M.
  • Quicktime Pro features are now a freebie and include some new graphical and editing hotness and a "HUDless" mode.
  • Screen recording.
  • New Language and Text Preferences allow for text substitution.
  • Split Terminal. I never used this before, but who knows, maybe now I will. I'm just always thrilled to see Apple constantly updating an app as proletarian — but important to us admins — as the Terminal.

That's a pretty long list with as many interesting new features as in any previous release. Sure it's low on the eye candy stuff, but you know? I can live with that.

I'm really looking forward to Snow Leopard. With the speed and size improvements and the handful of really useful new features, I think it's going to be great.

Portable Home Directories Part 1: What a Mess!

Now that I've tried it myself, I've very much enjoyed the advantages that having a network home account has offered. I've also rather disliked some of the disadvantages. Ultimately, the biggest drawback has been that when our production crew is doing a lot of rendering, my home account slows to a crawl and I can't get work done. Okay, I can, but not without a lot of swearing, and the fellas in the other cubicles just ain't digging that, believe me.

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 Accounts

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

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 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.

Software Update Server

I can't believe I never wrote this up, but I've been using the Software Update Server included with Mac OS X Leopard Server since I upgraded the servers at my old job. If your network — or Apple's servers — are ever slow to get updates, having your own centralized SU Server can make a world of difference. But it's most useful when you have a bunch of Macs you need to update all at once. Try doing ten or so over the Internet at the same time. You'll get errors and failures, and you'll kill your network pretty quickly as all those updates come in at once. But updating a lab full of Macs from your own dedicated Software Update Server will not only not fail, it'll actually be quite fast since your using only internal bandwidth, of which you should have plenty. Setting one of these up is pretty easy, but there are a couple gotchas I always have to remember. So here we go.

  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 Service 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!