Lion Server upgrade breaks Casper HTTP shares

This was an interesting one. Working on setting up Casper package and script deployments for spring semester, I found that no policies I created were executing properly. The JSS error logs looked something like this:

/usr/sbin/jamf is version 8.22
Executing Policy Run Script…
Error: The script could not be found on the server.

At first, I thought the double slashes were the problem, and verified that they appeared in every policy with a history of recent failures. This was a red herring (tried to access both single and double-slashed versions of the URL via a browser, and both failed), but it did lead to my next discovery: every policy execution since 5 October had failed.

That was about the time I upgraded my  Xserve to Lion Server (which also led to Tomcat and mysqldump problems with the JSS). I called in to support at this stage, and after a while mucking around with permissions propagation and a few other dead ends, they pointed me at a KB document on troubleshooting an HTTP distribution point. After a false start, this lead to the solution. I had to recreate a symlink to my Casper share in the Web server directory, like so:

sudo ln -s “/Volumes/Path/To/MyCasperSharePoint” /Library/Server/Web/Data/Sites/Default/MyCasperSharePoint

Restarted the Web service, tried a manual pull of a test policy, and it worked. Just one more bit of fallout from the Lion upgrade. Now I just have to re-execute all my failed policies.


Automatically mount drives with ignore ownership enabled

I understand that the first comment you make is likely to be “but that’s what the OS does by default.” Which is true, but apparently only so long as the drive in question doesn’t have an OS installed. For reasons that don’t bear explaining, I carry a lot of my personal data (particularly my iTunes library) on a bootable external drive that I attach to the lid of my MacBook Pro.

At work, I like to connect the drive via FireWire, and have my local account on the MBP set to find the iTunes library on the external. It works well, with the notable exception of having to use the Inspector to set Ignore Ownership every time the drive mounts. Yes, yes…I could have modified permissions on the drive. Again, for reasons that don’t bear explaining, I don’t want to do that. Besides, that’d be easy, and where’s the fun in that?

Arek Dreyer suggested a launchdaemon or similar. This was easy enough to set up with Lingon, using a WatchPaths key set to observe /Volumes. Patrick Fergus, on the MacEnterprise list, responded to a query with a complete script.


# Ensure we have a volume name

if [ $volumeName = INSERT_VOLUME_NAME ]


echo Error: volumeName must be set

exit 1


echo Checking volume permissions status

vsdbutil -c “/Volumes/$volumeName”


echo Setting “Ignore permissions” on volume $volumeName

diskutil disableOwnership “/Volumes/$volumeName”


echo Rechecking volume permissions status

vsdbutil -c “/Volumes/$volumeName”

This I dropped into /Library/Scripts, with read and execute permissions set. Connected a test drive and bingo! Success. Patrick was even thoughtful enough to have it log its operations. Which produced an interesting related line of inquiry. Running vsdbutil -c against and drive produced an error similar to

11/17/11 12:12:31.348 PM org.myorg.ignoreownership: No entry found for ‘/Volumes/VolName’.

A bit of googling around produced a relevant message board thread, and a check of my volume status database revealed a faulty entry in slot 1. Per the advice in this post, I whacked the db and rebuilt and lo, there was proper status checking!

So now I have a daemon that automatically sets ignore permissions on my external at mount. Oh, and a clean volume status database.

(Hat tips to Arek Dreyer and Patrick Fergus.)

Find My iPhone troubleshooting: Is this really an issue?

Rhetorical question, really. At JAMF’s 2011 (Inter)Nation User Conference, I saw at least one case where it was definitely an issue. Still, I can’t imagine it pops up that often. Anyway, according to Apple, no individual Apple ID can register more than 100 iOS devices. So if you’re planning a mass deployment, better figure on an appropriate number of institutional Apple IDs, if that’s how you plan to roll.

That interesting tidbit and more iCloud Find My iPhone troubleshooting here. Tip of the hat to Rich Trouton for find the KB article.

On the value of patience (and multiple tools)

MS Outlook 2011 for Mac is a great teaching tool. Pretty much every time I deal with it, I learn about something else annoying it does. I may even learn a new curse or two.

Today, though, it’s teaching me something I actually value: patience.

I’m sitting in a client’s office, staring at her iMac while Outlook’s Database Utility chugs away at a rebuild following a restore from backup. Not that you’d actually know it’s doing anything. The progress bar is still. Has been for most of half an hour. The console isn’t showing me diddly, except that spindump is monitoring the DU’s process.

Activity Monitor’s entry for the DU is blazing red at me, and telling me that DU isn’t responding. At first, I nearly gave in to the temptation to drop the process and call it crashed. And then I noticed that CPU usage was steady at about 30%.

Disk activity was similarly steady, showing a ton of reads. So I wait. Like magic, a few minutes later the rebuild completes, and DU springs back to life to notify me. Outlook starts normally, and we’re back in business.

There are two lessons here for any tech worth their salt. First, be patient. Not everything answers the system’s monitors as it should (are you listening, Microsoft?). Second, look in more than one place to see what’s going on. If I’d placed my trust solely in the DU GUI, or even in the Finder, I’d have believed that the process was hung and static. But a quick look at two further measures of activity showed me that it was running, just not being very nice about telling me so. So I remind myself once again of the value of multiple tools.

802.1x PEAP authentication errors under Mac OS X Lion (10.7.2)

UPDATE: I have it from a source I trust that the “Unknown” not-a-certificate mentioned below is ignorable, and will go away with 10.7.3.

Just bumped up against an interesting problem.

A client’s personal laptop was having problems authenticating to our Wi-Fi network. The machine is a black MacBook running Mac OS X 10.7.2. Our Wi-Fi uses Aruba access points to authenticate against our Active Directory using 802.1x, with additional security provided by a Bradford Networks NAC. Our 802.1x profiles are built automatically by our CloudPath XpressConnect tool (a Java Web-based utility). Normally, all this works quite seamlessly.
This particular client was seeing an odd response, though. After running (successfully) the CloudPath XPC setup routine, XPC attempted to switch the Wi-Fi to our standard secured network, and failed. The failure produced the following error dialog:
The identity of the authentication server could not be established. Contact your network administrator to verify your configuration settings.
This dialog appeared thrice before the MacBook finally quit attempting to join the network. Checking the logs, I found these errors:
eapolclient	peap_verify_server: server certificate not trusted, status 6 0
eapolclient	en1 PEAP: authentication failed with status 6
I checked in with our Wi-Fi admin, and confirmed that no certificates should be involved in this transaction, and that he hadn’t ever seen the cited PEAP errors, either. A cursory Google search didn’t help, either. My next shot was the keychain, so I made a backup of ~/Library/Keychains/login.keychain, and went looking.
The login keychain showed a number of keys that appeared to be spurious keys (several dozen). I deleted these, and got no change in behavior (predictably). Next, I ran Keychain First Aid, and got the following error:
User differs on ~/Library/Preferences/, should be 501, owner is 0.
Repair and rescan.
Keychain search list not properly configured.
Repair and rescan. Finally, no errors, but the error dialog on Wi-Fi connection attempts still appears. At last, in what might be considered a mild fit of pique, I deleted all references and files for the login keychain, logged out, and logged back in to recreate it. Lo! There was Wi-Fi! As it should, the system queried for the user’s AD credentials, and added them to the login keychain. Swapping the old keychain file back in made the problem reappear, so clearly the keychain was the problem. But why?
Regrettably, I don’t have a definitive answer. The client needed his machine back, and breakfix was a higher priority than investigation. However, I did notice that after connecting to Wi-Fi, the new login.keychain contains only a half-dozen entries…one sort of suspicious.
  • Two keys (private and public) and one certificate (surprisingly listed as untrusted). These are associated with iCloud, which the client confirmed activating.
  • One Apple Persistent State Encryption application password. Google that for a list of brief, generally uninformative explanations that basically amount to “it’s a Lion thing.”
  • One 802.1x credential (for our secure Wi-Fi).
  • Most interestingly, one “certificate” named Unknown, and marked as untrusted. This reappeared each time I removed and recreated the keychain. Its inspector says its data is not recognized as a certificate, and no similar entry appears on my own Lion laptop, set up via the same procedure.
The short story here is that if you get weird certificate errors with 802.1x and Lion, you could do worse than looking hard at the login.keychain. The longer story is that I’m not sure what was borked, or why the new keychain worked, but I’m very curious about the Unknown “certificate.”
Pity I won’t get to run down an answer.

Custom Vibrations in iOS

(It’s been a while. So shoot me.)

One of the new features of iOS 5 is the ability to set not only custom ringtones for specific contacts, but also custom vibrations. This is a boon for those of us who tend not to notice the default “buzz, buzz, buzz”, and has the added benefit of really shocking your officemates when it rattles the table during a meeting.

To enable custom vibrations:

  1. Open your iPhone and tap the Settings app.
  2. Tap General > Accessibility, and in the Hearing section, enable Custom Vibrations.
To set a custom vibration for a contact:
  1. Open the Contacts app (or access Contacts from the Phone app).
  2. Open the desired contact, and tap Edit at the top right.
  3. In the same grouping with Ringtone, tap Vibration.
  4. Note the default is Alert. You can also choose from a selection of preconfigured “Standard” vibes: Alert, Heartbeat, Rapid, S.O.S. or Symphony. (Don’t know about you, but I’m finding “Heartbeat” a tad on the creepy side.)
  5. To set a custom vibe, slide down to Custom and tap Create New Vibration.
  6. In the New Vibration windows (Collective Soul should sue for royalties), tap the vibration pattern you want. Note that you can hold a tap down to sustain the vibration. Your custom vibe can be up to 10 seconds long. Tap Stop when you’re done.
  7. Not sure how it went? Tap Play to run your new vibe back. Tap Record to rerecord the vibe, or Save to keep it.
  8. Give your new vibe a name, tap Save again, and you’re done.

Your new vibe pattern will appear in the list of custom vibes, and can be added to any contact. To remove a custom vibration, open the Vibration assignment window, tap Edit, and delete the ones you no longer want.

You may also notice that you can specifically assign a vibration type of “None” to any contact. Handy, I suppose, for those people you really want to ignore.
There’s another handy tool in back in the Accessibility sheet. Immediately beneath the Custom Vibrations slider, not the LED Flash for Alerts setting. This blinks the LED camera flash when an alert arrives. Helpful if, like me, you’re prone to miss it when your iPhone vibrates.