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

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.

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.

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

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.

DeployStudio creates root images with the name "DeployStudioRuntime.sparseimage". It also says so in the NBImageInfo.plist's RootPath key. For some strange reason, using the "Other NetBoot" command sets the root path to "NetInstall.dmg". You can see it clearly by starting up in verbose mode or reading setenv. I suspect it's just a bug and that AST doesn't actually check the plist and reported it, but didn't get a clear answer.

The result is you get a "stop" sign when you try to boot the NBI (machine gets the booter file via TFTP, but not the root image).

In any case, the workaround is simple - just rename DeployStudioRuntime.sparseimage to NetInstall.dmg every time you create your DeployStudio NBI with the DeployStudio Assistant and all will be fine. I just got bit by this the other day again and thought I'd write it down.

• Warranty status
• Part lookups
• Checking repair details and status
• Downloading part return labels

That's right - you can even use this to quickly download the return label of a part as a PDF:

./gsxcl -u username -p password -s sold-to -m label -q return-order:part-number > test.pdf
file ./test.pdf
test.pdf: PDF document, version 1.4

The operating principle is that -m defines the "mode" of operation and then everything after -q should supply the necessary arguments. Multiple arguments are separated with a colon, as for example in the label download command - we must supply both the return order number (starting with 7...) and the part number being returned.

usage: gsxcl -s sold-to -u username -p password [-r region] [-e environment] [-f format] [-m mode] [-q query]
-s  sold-to           your GSX Sold-To account
-u  username    the Apple ID with GSX WS API access
-p  password    the password for the Apple ID
-r  region           either "am" (America), "emea" (default, Europe, Middle-East, Africa) "apac" (Asia-Pacific) or "la" (Latin America)
-e  environment the GSX environment. Either empty (production), "it" or "ut" Defaults to production
-f  format          the output format. Either print_r (default), json, xml or csv
-m  mode          what to search for. Currently one of: warranty, parts, pending, repair, lookup, status, label.
              Defaults to "warranty"
-q  query           a query string (serial number, order confirmation, repair number, EEE code, etc
              Defaults to this machine's serial number

One of the most recent changes I added was the format option, allowing you to get data out of it in CSV, XML or just a PHP print_r(). The CSV option is probably the most useful one, the header row is constructed from all the property names of the GSX WS response.

Running it with just the required arguments will perform a warranty status check for the current machine.

This is actually pretty cool - it gives you access to all your installation media, right within DeployStudio, your users don't have to "learn Terminal" and you no longer have to worry about individual diagnostics OS being up to date - it's all in NetBoot.

For our environment, I created 3 workflows:

• "Boot Bundled Installer" which calls NetBless without arguments, allowing it to choose the appropriate OS. Since NetBless returns 1 when the original installer is not found, you get a failed result when running the Workflow, which is perfect.
• "Boot 10.6 Installer" calls NetBless with retail_10.6.3.nbi which is a NetInstall set of a retail 10.6.3 disc
• "Boot 10.5 Installer" calls NetBless with retail_10.5.8.nbi which is a NetInstall set of a retail 10.5.8 disc

You can copy netbless.sh to the Scripts directory and call it from a "Generic task" or just copy/paste it into a "Generic task" as is.

Very simple to use, you don't even have to know the WSDL URL:

<?php

  include 'gsxlib/gsxlib.php';
  $gsx = new GsxLib('your sold-to account', 'gsx user', 'password');
  $info = $gsx->warrantyStatus('serialnumber');
  echo $info->productDescription;

?>

MacBook Pro (15-inch 2.4/2.2GHz)

Currently it only has a shortcut for warranty status checks, more to come soon. Check the readme for more details.

On a totally unrelated note - imapsync is awesome.

But which switch are you actually connecting to?

I assumed it was the one on the other end of the Ethernet cable. Checking the VLAN configuration revealed there were none so I assumed this switch was only part of the network I was deleting (I was combining two networks) and then just connected this switch to the other network.

And then nothing worked. And I spent the next 3 hours fixing things and got home around 2 AM...

I know now I had created an Ethernet loop. The switch I was configuring wasn't actually the switch I was physically connected to, but some random one of the three identical 1800's we have in our office (the 1800 actually supports STP, which I've never used, until now). After disconnecting all other cables from the switch I saw that this one did indeed have 3 VLAN's and that the one I connected to the "other network" was actually the same one.

OK, so no default IP's for managed switches. Ever. But which one do you give them then? My experience with switch IP's is that no-one ever remembers them since they're usually used very rarely (along with their admin passwords, but that's a different "IT tip of the month"). Well, you use the 2 databases that occur naturally in any network - DNS and/or your firewall's configuration (DHCP static map). In this case, I chose the latter.

• PHP's gettext support made me want to smoke crack so I ported the entire servo localisation to one based on JSON. Also, POEdit is rubbish so I feel much better now. Also wrote a simple tool to convert existing PO files to JSON.

• The only thing I was missing from POEdit was the ability to quickly scan the sources for updated strings. So I wrote this thing which actually works pretty well. By the way, my gettext function is called __().

• MTK now includes a tool to report the build number of any OS X volume. In case you ever have to match any of these.

• iTunesScrubber now has a "GUI". It's a simple droplet that contains the AtomicParsley binary and my script. Just drop your iTunes Store M4A(s) on it and it'll ask for a destination folder for the cleaned files.

• Apache 2.2 (at least on FreeBSD) comes with a weird WebDAV default configuration which causes every /uploads URL to trigger an Access Denied error, such as this:

  client denied by server configuration: /usr/local/uploads
  

The solution (if you need DAV support in the first place), is to edit /usr/local/etc/apache22/extra/httpd-dav.conf and set

Alias /uploads "/usr/local/uploads"

to something else. Sounds obvious now, but was driving me nuts...

• Indiegogo.com seems nice. It's exactly the kind of thing I was thinking of a while ago. I found it because a friend of mine is working ona movie project and they're trying to raise some of the funding through that. Go check it out!

I'm happy to report that the system seems to be running fine (for a few months now), the only thing that didn't work at all was the startup script, so I had to create one from scratch:

#!/bin/sh
#
# PROVIDE: virtualmin
# REQUIRE: LOGIN
# KEYWORD: shutdown
#

. /etc/rc.subr

name="virtualmin"
rcvar=${name}_enable

load_rc_config $name

: ${virtualmin_enable="NO"}

start_cmd=${name}_start
stop_cmd=${name}_stop
extra_commands="restart"

virtualmin_start() {
  /usr/local/etc/webmin/start
}

virtualmin_stop() {
  /usr/local/etc/webmin/stop
}

virtualmin_restart() {
  /usr/local/etc/webmin/restart
}

run_rc_command "$1"

Save that into /usr/local/etc/rc.d/virtualmin, chmod +x and set virtualmin_enable="YES" in /etc/rc.conf.

sudo bless --netboot --booter tftp://server.apple.edu/NetBoot/NetBootSP0/NetInstall.nbi/i386/booter \\
--kernel tftp://server.apple.edu/NetBoot/NetBootSP0/NetInstall.nbi/i386/mach.macosx \\
--options "rp=nfs:server.apple.edu:/private/tftpboot/NetBoot/NetBootSP0:NetInstall.nbi/NetInstall-Restore.dmg"

Where the IP of server.apple.edu would be at the other end of the tunnel. The problem is, this requires a working system and isn't particularly "user firendly".

Our goal was to give our reseller partners the opportunity to run Apple Service Toolkit. AST is a completely EFI-based system so the amount of data transfered is relatively tiny. An entire MRI session is perhaps a few dozen megabytes, so I knew it should not only be possible, but might actually work quite well.

The only question was how do we make the whole experience seamless - to have customer simply start up the Mac with the N-key and have it work as if on the same subnet as the AST server. The whole solution would consist of:

• A pfSense (1.2.3) system at both ends. We happened to have a few spare PC Engines Alix.2 boxes so we used those.
• OpenVPN (2.0.6) as the VPN software (included in pfSense)
• A Mac mini running 10.6.5 server and AST 1.0.5.

OpenVPN bridging

For DHCP broadcasts to work, we need to bridge the local and remote networks. There's quite a lot of information on this out there, but I found that most instructions dealt with bridging a specific client to the remote network. What we needed, was a bridged site-to-site connection. Setting it up turned out to be quite a bit easier than I thought, here's how I did it:

1.

I set up a static IP on the WAN

2.

Configure a new OpenVPN server (VPN > OpenVPN > Server > Add).

• Protocol: TCP
• Address pool: to my understanding, this is meaningless in this case, but it made sense to set it to something within the NetBoot server's subnet, but outside the internal DHCP range.
• Enable "Use static IPs". Presumably because we want the internal DHCP server to assign IPs.
• Authentication method: PKI. This is a prerequisite to "Use static IPs".
• Under "Custom options" add "dev tap0"

The other fields should be set according to your own requirements.

When you save all that, pfSense will try to start up the newly configured OpenVPN server. Assuming everything was kosher, this will create a new network interface on the box, called tap0. This is the interface that your VPN clients will connect to and works just like a physical interface.

All that remains is to bridge this new interface with the LAN, where your DHCP and NetBoot live. You could do this through the WebGUI (Interfaces > Assign, etc) and it would work, but only until you reboot the VPN box. This is because pfSense's start up sequence tries to assign bridges before starting the OpenVPN server. Fortunately, we can circumvent this quite easily.

In WebGUI, open Diagnostics > Edit File and load up /conf/config.xml. Append the following to the element:

<earlyshellcmd>ifconfig bridge0 create</earlyshellcmd>
<earlyshellcmd>ifconfig bridge0 addm vr0 up</earlyshellcmd>
<shellcmd>ifconfig bridge0 addm tap0</shellcmd>

That looks a bit weird at first, but it makes sense, knowing that OpenVPN is initialised between and . Save the file and reboot the box to make sure tap0 and bridge0 are still there. vr0 is the LAN port on the Alix.2 board. This concludes our server part of the program.

3.

Over on the client side, it's almost a mirror image of the server, only a bit more simplified. VPN > OpenVPN > Client > Add:

• Protocol: TCP
• Server address: WAN IP of server
• Server address: empty
• Interface IP: empty
• Authentication method: PKI

Once you save that, the tunnel should be up, but broadcasts shouldn't work yet since we haven't defined the LAN/TAP bridge. Load up conf/config.xml and do the exact same change as on the server side. Reboot to verify it's working. The last thing I had to do, was to make sure the IP of the VPN client's LAN port was within the server-side network. Without this, broadcasts would work, but I couldn't actually connect to anything on the remote network.

Oh, and make sure you've disabled the DHCP server on the LAN port.

4.

After the reboot, connect a machine to the LAN port. You should get an IP on the (now) remote network. Startup Disk should see the NetBoot server on the remote network (the AST NBI in our case). Booting up the machine with the Alt-key should also list the NetBoot server (with recent enough firmware). Booting with the N-key should boot the machine over the VPN connection.

Finishing touches

For extra style points, you can have OpenVPN flash the LED's on your client (the Alix.2 board in my case), by using the "up" and "down" parameters to OpenVPN (Custom Options field in pfSense), for instance:

up "echo 1 > /dev/led/led2"; down "echo 0 > /dev/led/led2"; up-restart"

The "up-restart" option will run the commands for VPN restarts as well.

The Setup

• We collect CPU installation media from customers and resellers and then rip them to the file server. I rip both disks into a folder named after the "mnemonic" name of that machine. For instance, "MacBook Pro (15-inch, Late 2008)" becomes "mbp_15_l08" etc.

• I then use System Image Utility to create NetInstall sets of all ripped images and name the .nbi's according to the machine's hardware "model", for instance "mbp_15_l08" then becomes "MacBookPro5,1". You can read the model of a machine either from Mactracker, System Profiler or simply:

  $ sysctl -n hw.model
  MacBookPro3,1
  

• The reason I use two different naming schemes is because the first makes the images easy to browse for technicians and the second makes them easy to match to a specific machine (the first is easy to remember for humans, the second for machines, if you will)

• The NetInstall sets are then transfered to a folder where they are accessible to NetBoot (see my previous post for specifics).

Making it Run

With things organized this way, it's now very simple to match any machine to it's corresponding installation media. To automate this, I created a tool that consists of two parts:

• A web service (which runs on the NetBoot server) that lists all the available NetInstall sets
• A command-line tool (essentially just a wrapper for bless) that can query the web service and set the appropriate boot args for a given NetInstall set

The web service couldn't be any simpler, it just lists the available NBIs:

<?php
$datadir="/data/nb";
header("Content-type: text/plain");
foreach (glob("${datadir}/*.nbi") as $nb)
{
    $images[] = basename($nb);
}
echo implode(" ", $images)
?>

By default, the client-side tool tries to match the current machine to a set on the server:

$ sudo ./netbless.sh 
Error: model MacBookPro3,1 not found on the NetBoot server

... meaning I haven't ripped the media for this machine yet. In these cases I can force the tool to use a specific NBI. To do that, I'll probably need to know what is available:

sudo ./netbless.sh list
Available images: 10.5.6_retail.nbi MacBook3,1.nbi MacBook7,1.nbi MacBookAir2,1.nbi MacBookPro5,2.nbi MacBookPro6,2.nbi MacBookPro7,1.nbi Macmini3,1.nbi Macmini4,1.nbi boot.nbi iMac11,3.nbi retail_10.6.3.nbi retail_10.6.3_2.nbi

So, to boot to the 10.5.6 installer, I would say:

sudo ./netbless.sh 10.5.6_retail

The script makes some assuptions (for instance of the NetBoot and web services being on the same server) but is general enough to customise it to any environment. If you're image library is comprehensive enough, using netbless is usually just a matter of:

$ sudo ./netbless && reboot

And yes, using this requires a bootable system to start with (say your known-good diagnostics partition). Ideally, netbless would be an EFI-binary that you could run off a memstick, without an OS, but my EFI-programming skills aren't quite up to snuff yet...

The Specs

• I built this system for our Authorized Apple Service Provider where we use it primarily for NetInstalling machines after a hard drive replacement. Getting the right system on the right machine is crucial and NetBoot provides the best platform to do so, in my opinion (as opposed to, say having dozens of drives and/or partitions of installers for every possible Intel Mac, for each of your technicians).
• We don't need diskless support (something I'll probably have to address sooner or later).
• We don't support PPC machines (haven't had the need to do so thus far).

The server is running FreeBSD 8.1. I create the NetBoot images using System Image utility (I have a machine with both 10.5. and 10.6 installed so I can create images of both systems). The images are stored on a RAID-Z pool under /data/nb.

Installation

NetBoot essentially consists of 3 pieces (in order of appearance):

• A DHCP server to provide addressing and initial server discovery
• A TFTP server for transferring the kernel and extension cache
• An HTTP or NFS server to provide the actual disk image data

NFS and TFTP are essentially "built in" to FreeBSD, so we only need to install ISC's DHCP server:

# cd /usr/ports/net/isc-dhcp41-server
# make install clean

On to configuring the DHCP server. I'm assuming you already have the basic functionality sorted and will only focus on the NetBoot-relevant bits:

# nano /usr/local/etc/dhcpd.conf

To which we append the following:

class "AppleNBI-i386" {
  match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
  option dhcp-parameter-request-list 1,3,17,43,60;

  if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; }
  if (option dhcp-message-type = 1) { option vendor-encapsulated-options 08:04:81:00:00:67; }

  filename "boot.nbi/i386/booter";
  option root-path "nfs:172.17.65.1:/data/nb:/boot.nbi/NetBoot.dmg";
}

The first four lines inside the class section - I have no idea what they do, but I haven't tried this without them, so there they are. The last two however make perfect sense - the first defines the path of the booter file (the low-level EFI binary). This is always relative to the root of your tftp server, which by default is /tftpboot. Since my only application for tftpd is NetBoot, I simply symlink /tftpboot to my NetBoot image set repository:

# ln -s /tftpboot /data/nb
# ls /tftpboot
MacBookPro5,2.nbi   Macmini4,1.nbi      boot.nbi        retail_10.6.3_2.nbi
MacBook3,1.nbi      MacBookPro6,2.nbi   MacBook7,1.nbi      MacBookPro7,1.nbi   iMac11,3.nbi
10.5.6_retail.nbi   MacBookAir2,1.nbi   Macmini3,1.nbi      asd_efi_3s123       retail_10.6.3.nbi

I like to name all my CPU-specific install images based on their "Model Identifier" (sysctl hw.model, more on "why" in a later article...). As mentioned previously, the sets are all created using SUI. boot.nbi is a NetBoot set, preferably of a really fresh retail package (or the latest CPU bundle) which is used as the default set. As you can see, I also have an Apple Service Diagnostic image in there, more on that some other time...

The last line sets the network path of the actual NetBoot "payload" - the OS and/or installer that will be booted and mounted. The colons are significant - "nfs" means the file sharing protocol (which will set up in just a bit), "/data/nb" is the path of the NFS share and is separated from the IP of the server so that the client (in our case the OS X kernel) knows what to mount and finally "/netboot.nbi/NetBoot.dmg" is the path of the actual disk image to be mounted.

All that remains is to let dhcpd know we mean business:

# /usr/local/etc/rc.d/isc-dhcpd restart

TFTP and NFS

With DHCP set up, let's configure and test the two other components of this system, starting with TFTP:

# nano +28 /etc/inetd.conf

Uncomment the current and following line and kick inetd:

# /etc/rc.d/inetd restart

Test it by downloading one of the booter files from any Mac. In my environment this would mean:

$ tftp 172.17.65.1
tftp> get boot.nbi/i386/booter
Received 322301 bytes in 14.1 seconds
tftp> quit
$ file booter
booter: Universal EFI binary with 2 architectures, x86_64, i386

Ignore the insane slowness, I'm testing this over VPN. Notice the path that we "get" is exactly the same as the filename parameter in dhcpd.conf. If you didn't get the "Received..." line, try the same thing locally on the server and go from there...

NFS can be a bit more involved and I'm tempted to simply point you to the handbook, but in a nutshell:

# nano /etc/rc.conf
rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"
# echo /data/nb >> /etc/exports
# rpcbind
# nfsd -u -t -n 4
# mountd -r

You can test the NFS connection from the Finder, with Command-K > nfs://172.17.65.1/data/nb. A number of things can go wrong here, I strongly suggest you check the handbook as well as the server and client logs (may the Lords of Cobol be with you).

Taking it for a spin

Everything should now be set up and ready to go. Grab an Intel Mac and boot it with the N-key. You should see the big globe icon (looking for the server), followed by the Apple logo and spinning globe (downloading kernel) and then the normal progress indicator (mounting the DMG and booting). If you get a kernel panic, then booting with N and then Command-V will usually give you a hint as to what's wrong.

Any number of things could have gone wrong here and I can't recommend Mike Bombich's excellent Troubleshooting the NetBoot Process article enough (thank the gods it's now hosted in a safe place on AFP548).

Does this mean that...

... you can use any PC server to NetBoot Macs? Yes. But in all honesty, this is all little more than a clunky workaround for sysadmins desperately strapped for cash (not to mention too much time on their hands). And even though it also serves as a nice "training program" for understanding the inner workings of NetBoot, Apple's solution is much nicer and waaay easier to use.

For example, as it stands, this system will not support diskless NetBoot, and only the default NetBoot set will be available from the firmware. As I understand, this is because Apple actually uses a proprietary DHCP server (not the stock ISC one that we installed) that has a "special relationship" with the Mac firmware. Oh, and you can forget about limiting certain Mac models to certain NetInstall sets (which would be nice).

But this system works surprisingly well for us and so I decided to write it down. There's actually one more piece of the puzzle (a "secret sauce", if you will) that makes this whole thing a bit more useful (which I call "netbless"), but more on that some other time... :-P

There are also some improvements - you can now specify the output path (defaults to the current directory) as the first argument as well as run it with any number of optical drives (I tested it with 2). The discs are also ejected automatically after a successful rip. And most importantly, the tool is now licensed under the WTFPL. ;-)

Grab the source or universal binary from Github.

...timeless words from possibly one of the most memorable ad campaigns ever conceived. Apple.com even had a hidden page set aside for "Think Different" long after the actual campaign had ended.

Why this sudden trip down memory lane? Because I was sifting through some OS X application icons and this is what TextEdit looks like at 512x512:

Oh, and many thanks to all of you who've sent feedback about my site. I've made some improvements (you can now browse all the tags if you click on the "Blog" link and am working on getting the archive and search to work properly as well).

This is where iperf comes in:

Iperf was developed by NLANR/DAST as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.

In other words it can do a hell of a lot more than just generate traffic, but that's what we'll use it for this time. iperf consists of two parts - a client and a server. I run our server on our FreeBSD box:

$ cd /usr/ports/net/iperf
$ sudo make install clean
$ iperf -sD

That installed iperf and launched it as a server in the background. Now we need to run the client on the machine we want to test. For this, I created a dead-simple AppleScript wrapper for iperf (which also includes the iperf binary itself), just double-click and enter the address of the iperf server. This launches iperf with some options apropriate for long term testing, in a new Terminal window.

The script (called "aptest", also part of MTK) tries to bind the iperf instance to the AirPort interface. This will wreak havoc on your wireless network - I would advise to set up a separate base station for this kind of testing. :-)

It would be fun to one day create a proper GUI that would plot the CSV output of iperf, but this will have to do for now...

One of the interesting facets of starting a business is that you don't have any money. This forces you to find creative, and most importantly, cost-effective (i.e. free) solutions to problems. For example, our service center is divided into two networks - the "office" network (employee's machines, printers, servers) and the "service" network (customer machines).

The only server license we could afford is being used by the Mac mini server in the office network, providing mail, wiki, calendar and chat services. But we also needed a robust system to host netboot, AFP, NFS and local Software Update services as well as to act as a secure gateway between the service and office networks. So I built a PC, set it up with 3 drives and RAID-Z and two gigabit NICs and FreeBSD - all for roughly half the price of a Mac mini server.

Now the question was how do I get this PC to act as a Software Update server to all the service machines. There's actually a million ways, here's just one:

The pieces

First, let's find out where all the software update data is:

$ defaults read /etc/swupd/swupd updatesDocRoot
/Volumes/Drobo/SoftwareUpdate/

I wanted to avoid using any messy authentication (since software updates aren't exactly trade secrets), so I set up a read-only rsync repository on the Mac mini to share the software update document root with a very simple rsyncd.conf file:

[sus]
comment = software update server
path = /Volumes/Drobo/SoftwareUpdate/html
readonly = true

That's all the changes we have to do to the Mac server. On the FreeBSD side, we need to install lighttpd and dnsmasq:

$ cd /usr/ports/www/lighttpd
$ sudo make install clean
$ cd /usr/ports/dns/dnsmasq
$ sudo make install clean

The FreeBSD server also functions as a DHCP server for the service network and sets itself as the primary DNS server for all the DHCP clients. The idea was that we wouldn't have to make any changes to the customer's machines to have them use our local SUS, ie to use a transparent software update solution. So I added these lines to /usr/local/etc/dnsmasq.conf (172.17.65.1 is the IP of the FreeBSD server):

address=/swscan.apple.com/172.17.65.1
address=/swcdn.apple.com/172.17.65.1
address=/swquery.apple.com/172.17.65.1

I then create a directory for the SUS data on my RAID-Z, ZFS pool:

sudo mkdir /data/sus

and edit /usr/local/etc/lighttpd/lighttpd.conf to use the SUS docroot as the default docroot:

server.document-root = "/data/sus/"

Then just fire up dnsmasq and lighttpd.

Making it run

The final step is to put it all together. At first I thought it would be a trivial matter of just dumping the data, but there are some additional steps that need to be taken, so I threw together this little script:

#! /usr/bin/env bash

if [[ $# -lt 4 ]]
then
  echo "usage: $(basename $0) server repo port destination" 2>&1
  exit 1
fi

MAC_SERVER=$1
REMOTE_REPO=$2
REMOTE_PORT=$3
LOCAL_DOCROOT=$4
HOSTNAME=$(hostname)

# download latest update packages, removing deprecated
rsync -av --delete rsync://${MAC_SERVER}:${REMOTE_PORT}/${REMOTE_REPO} ${LOCAL_DOCROOT}

if [[ ! $? ]]
then
  echo "Failed to fetch software update content" 2>&1
  exit 1
fi

# update hostnames in catalog files
find ${LOCAL_DOCROOT} -name *.sucatalog -type f -exec sed -i '' "s/${MAC_SERVER}:8088/${HOSTNAME}/g" {} \;

# rebuild symlinks
cd ${LOCAL_DOCROOT}
rm ./index*
ln -s ./content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog ./index-leopard-snowleopard.merged-1.sucata$
ln -s ./content/catalogs/others/index-leopard.merged-1.sucatalog ./index-leopard.merged-1.sucatalog
ln -s ./content/catalogs/index.sucatalog ./index.sucatalog
# 10.4 seems to need this
ln -s ./content/catalogs/index.sucatalog ./content/catalogs/index-1.sucatalog
curl -o ${LOCAL_DOCROOT}/scanningpoints/scanningpointX.xml http://swscan.apple.com/scanningpoints/scanningpointX.xml

Save that into a file and run it:

$ ./supdate.sh macserver.example.com sus 874 /data/sus/

If all worked as expected, save it so that it's run periodically (say, once a week). Notice that the script is assuming the Mac server was hosting the updates on port 8088! I had a version of the script that actually read the repo path and port from the Mac server using SSH, but I like this solution much more - no authentication required.