One cool addition to Lion, at least from a techie's perspective is System Information (previously known as System Profiler). On the outside it looks pretty much like System Profiler, with all it's categories:

... but, hit Cmd-I and voila:

Notice the title of the window. I'm guessing this will one day replace the venerable "About This Mac" under the Apple menu. This thing could be pretty useful since it tells you how you're hard drive space is distributed:

... and about the current and possible configurations of RAM:

The "Support" and "Service" tabs hold some useful links but unfortunately they all seem to go to blank pages at the moment.

I've started a pretty useful little project over at Github, called Auditron. It's essentially a wrapper for System Profiler that you can easily preconfigure and then distribute, say via email.

Very often you have to audit a bunch of totally unmanaged Macs and I know from personal experience that touching every machine yourself either doesn't work very well ("Umm, does anyone know the password to Joe's workstation?") or is simply impossible ("Umm, does anyone know where Joe's workstation is?"). The idea for this actually came from this very need back in 2006 - I was still working at Humac back then and some B2B salespeople really wanted to sell stuff but couldn't since they didn' know what the customer was running and therefore needed. Back then I threw together an AppleScript Studio app that did pretty much the same thing as Auditron but then you had to use a few command-line script to put the results back together.

This one is much simpler to use - first you run it on your own machine and set your name and email address (assuming you're the one collecting this information) then you just ZIP up the app and send to everyone at the office. When lauched, auditron runs System Profiler in the background, saves the results in a safe place and then tells (either Mail.app or Entourage) to create a new mail with the compressed system profile as an attachment).

The second part is comparing the results. Once you get all them back, you just save them into one folder, open Auditron and run the File > Compare Results command (Cmd-K) on that folder which should pop open a table with the basic info of every Mac in the folder. You can then export that as a CSV file for further processing in Excel.

I think this thing might also be pretty useful for AASP's for doing "remote" diagnostics (as in "Does that Early 2011 MBP really have the correct 10.6.7 update installed?"). We might even put it up on our website somewhere...

Download here. Bug reports preferably to Github, but you can also just drop me a line directly.

As an aside - I started writing this in AppleScriptObjC and can honestly say that that "language" or "platform" or whatever you want to call it is number 2 in my list of horrendous development environments (Symbian C++ is still king!). Luckily I hadn't gotten too far and was able to switch over to Cocoa pretty quickly. I suspect AppleScriptObjC (just look at the name of it!) is just Apple's way of trying to get all those poor AppleScript devs over to Cocoa/Objective-C (which I heartly recommend, considering the alternative). I just wish they'd make a statement about this thing already.

Back from our trip to NYC with my sister, we had a whole bunch of AVCHD material in MTS format that I just couldn't get into iMovie. So the idea was to first convert them to QuickTime. Turns out there's no shortage of "mts2mov" utilities out there but they're all crapware. Horrible Windows-look-alike contraptions with ridiculous pricetags and big honking "try now for free"-signs... yuck.

But then I turned to my old friend ffmpeg, downloaded, compiled and, as usual, had a fresh batch of QuickTime files ready for editing in no time at all.

But this got me thinking - why not have a general-purpose ffmpeg wrapper for these kinds of occasions. At first I wrote a simple Cocoa app but then came up with a better idea - a collection of Automator actions. It goes by the name of Mediator and right now there's only one action - "Convert into QuickTime" which simply uses ffmpeg (bundled into the action) to repackage an input file to MOV.

The compiled ffmpeg is for x86_64 so it'll only run on Core 2 Duo and beyond. Source and binary in Github.

There's one more new tool in MTK that I thought was worth a quick shout-out, namely cpu2asr. While netbless has turned out to be pretty useful, restoring entire CPUs with it has two drawbacks:

• You have to create a user account to install the bundled applications (the second disc)
• It's slow. While an installer-based workflow is great for doing "archive & install" — type installations, restoring a brand new drive with this method is much slower than a simple ASR restore.

So we need a method to create ASR-ready images from the bundled media. The obvious problem is the media will only install on the machine the it was designed for (i.e., you need to have an actual "MacBook Pro (Mid 2010)" to create the corresponding ASR image. With so many Mac models out there, this isn't always possible, especially if you're a service-only shop like us. And even if we manage to do this, doing "gold master" restores has some potential problems, with machine-specific settings and code being redistributed to several different units.

This is where cpu2asr comes in. It takes 3 arguments - disc 1, disc 2 and the name of the output image. The result is an ASR-ready image you can restore on a machine in minutes, via Deploy Studio or whatever. You can also run the tool on any Mac (there's an [incredibly crude hack to basically bypass all requirement checks).

So far I've managed to create both 10.5 and 10.6-based ASR images with it (the 10.6-based ones needed an additional step to extract the XAR archive for the patching to work). Since the "volumes" are installed "offline" never booted, you also avoid distributing and machine-specific settings.

So, in summary, the whole process becomes a simple matter of:

# cpu2asr Mac\ OS\ X\ Install\ DVD.dmg Application\ Install\ Disc.dmg imac_21.5_m10.dmg

The code could still use some cleanup (and a few more features, like the option to install additional packages) but I've now "imaged" half a dozen machines with this so it seemed safe to put it out there. Also, while digging through the OS X distribution files, I've found that one bundled OS build can support several Mac models, so it would make sense to figure out an efficient workflow for storing and distributing these (kinda like asd2nb, but storing it with the OS's build number, for example).

There's a new tool in MTK, creatively named asd2nb which helps put Apple System Diagnostic images on your NetBoot server. The idea and motivation is very similar to netbless — there are dozens of ASD discs, with more coming out with every new Mac model and managing them becomes more and more complicated in any AASP environment.

A word of warning - ASD OS tests are not currently designed to be run over NetBoot. In our testing we've seen several false positives and some tests (like NIC tests) even seem to hang. But considering the benefits, this is definitely something to try out and maybe even implement, once you know how to work around a few known issues.

Also, the EFI tests seem to work just fine.

The Workflow

We start by creating a NetBoot set from each ASD image using System Image Utility:

• Mount the ASD OS image, launch SIU and add the devices supported by the test to the "Filter Computer Models" action.
• Name the NBI by the test version (for example 3S145.nbi)

• Mount the EFI ASD image and rsync the contents under the new NBI, i.e.:

  # rsync -au ./Volumes/3S144\ ASD\ EFI/ ./3S145.nbi/efi
  

• Copy the NBI to your deployment server

The annoying part about this is of course having to do this on the same major OS version that's in the ASD image (which go back as far as 10.4 for 108 and 116). We have a machine with 3 partitions (10.4-10.6) set aside for this.

116 and 108

For some reason, the NBI created by 10.4 SIU will result in a kernel panic during boot. Even if you create the set on an Intel machine. Luckily the workaround is quite simple:

• Create the NBI using SIU as usual (saved into /Volumes/nb/asd/3S116.nbi in my case)

• Mount the original ASD 116/108 image (/Volumes/ASD\ Dual\ Boot\ 3S116) and then:

  # cd /Volumes/ASD\ Dual\ Boot\ 3S116
  # ditto mach_kernel /Volumes/nb/asd/3S116.nbi/i386/mach.macosx
  # ditto System/Library/Extensions.mkext /Volumes/nb/asd/3S116.nbi/i386/mach.macosx.mkext
  # ditto usr/standalone/i386/boot.efi /Volumes/nb/asd/3S116.nbi/i386/booter
  

Client & Server

A single ASD may support more than one Mac model which makes matching a machine with it's corresponding ASD a bit more involved. I chose to have a server-side script do the heavy lifting - it takes the machine's model ID as an argument and then scans the whole ASD NBI repository for each NBI's NBImageInfo.plist file for a matching string in it's EnabledSystemIdentifiers array, returning the NBI name, if successful. With this method, you don't have to make any changes to the client script — just keep adding new ASD images as Apple releases them using the workflow outlined above.

And what about EFI?

The client-side script accepts one optional parameter — "efi". If set, this will change the bless behavior to set the boot file to the EFI test's boot.efi binary. The EFI tests seem to work just fine over NetBoot without any weird false positives so far.

Some older tests (namely 3S108 and 3S116) came as one big DMG, with the EFI and OS tests on the same partition. You have to do a bit more preparation with these. For example, to make 3S116 fit our workflow, I mount the image and then:

# rsync -au /Volumes/ASD\ 3S116/System/Library/CoreServices/.diagnostics ./3S116.nbi/efi
# cd ./3S116.nbi/efi
# ln -s diags.efi boot.efi

If you use DeployStudio, you can create 2 workflows — "Boot ASD OS" which runs asdbless.sh as is, and "Boot ASD EFI" which runs asdbless.sh with the efi parameter.

In closing, I have a feeling this will all be integrated into AST some day (it would just seem logical), but until that day comes, this method gives pretty good results.