North Star Labs

Digging around in a NetBoot-Install.dmg file created by NetRestore Helper, I found a nice little gem.

In Leopard, and perhaps earlier versions of Mac OS X, we’re able to start a VNC server with the machine serial number as a password. This is particularly interesting for a managed network or lab environment.

As an example, I’m starting a VNC server in my NetBoot-Install image with the following shell script:

# Credit to Mike Bombich for this snippet

VNC="/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/MacOS/AppleVNCServer"

if [ -x "$VNC" ]; then
    "$VNC" -noRegister -serialNumber &
fi

I’m then able to quickly connect with Cmd+K in the finder:

If you’re scripting this, here’s a quick way to snag the serial number. I do this before I bless a client machine to netboot, so I have the serial number to connect back up once it’s in the NetRestore system.

system_profiler SPHardwareDataType | \
  grep -i 'serial number' | \
  perl -ple 's/.*:\s+(\w+).*?/$1/'

After upgrading all of my personal machines to Leopard, I’ve found myself using the Screen Sharing feature quite often. Many people have two Mac’s these days, particularly owners of the MacBook Air, and screen sharing makes it incredibly convenient to access a machine in another room.

As with most things I do frequently, Quicksilver has utterly spoiled me. The process of making the Finder active, pressing Command+K, and selecting or typing vnc://champ.local is just way too long.

Fortunately, it’s really easy to integrate Screen Sharing into our Quicksilver workflow.

Here’s how.

You’ll need to edit unix plaintext files, rather than rich text which TextEdit.app seems to insist on producing. TextWrangler is a great, free, text editor for editing Unix plain text files, although I’m partial to TextMate.

First, make sure Screen Sharing is turned on in the Sharing Preference Pane in Leopard.

Suppose you want to connect to a machine named “champ” in the Sharing Preference Pane.

The script will have the contents:

#!/bin/sh
# Nice and short
open vnc://champ.local &

Save the script into ~/Library/Application Support/Quicksilver/Scripts/champ.sh and make sure that folder is scanned by Quicksilver.

You’ll also need to make sure the script is executable, so open up Terminal.app and change the permissions:

chmod a+x ~/"Library/Application Support/Quicksilver/Scripts/"*.sh

That’s it. Now you should just be able to invoke Quicksilver, start typing the name of the machine you want to share the screen with, and presto! Nice and fast.

Joel just posted a great article titled SSL and LDAP in Leopard about the pitfalls of using SSL secured LDAP servers in Leopard. As Joel mentions, Leopard now refuses to trust any and all SSL protected LDAP servers out of the box.

A few people have complained that Directory.app, and the the LDAPv3 plugin for DirectoryService don’t honor the same purchased certificates that work just fine in their web browsers. Nor do they honor certificates signed by authorities listed in the x509Anchors keychain.

I’m not sure exactly where I personally stand on these very reasonable gripes, but I do know that it’s relatively trivial to configure all of your clients to honor “legitimate” certificates signed by authorities such as VeriSign, GeoTrust, etc…

It’s as simple as:

echo "TLS_CACERT /usr/share/curl/curl-ca-bundle.crt" >> \
  /etc/openldap/ldap.conf

You may need to give DirectoryService a kick, with killall DirectoryService.

This works because Apple already distributes a long PEM encoded list of certificate authorities for use with the curl command line utility. We’re able to leverage it’s trusted certificate store.

Also be warned your Leopard workstations are now slightly more vulnerable than if you were to configure only the certification authorities you need to get your LDAP server trusted.

James Reynolds mentioned on the Mac Enterprise mailing list that /etc/rc.local scripting is no longer a viable option to execute scripts at boot time, before the loginwindow presents itself to the user.

In Mac OS X 10.4, I’ve relied heavily on /etc/rc.local to execute a number of management scripts, and /etc/rc.local has always irritated me as a solution because of the parallel nature of sub-systems coming online during the Mac OS X boot process. Note; I didn’t say “boot sequence.” For example, I have some pretty extensive code to simply detect if DNS resolution is working or not.

Now that loginwindow is started from launchd, we’re able to replace it with our own scripts, and ultimately call it when we’re finished. I have yet to try this as a replacement for my current system, but I’m hopeful there aren’t as many issues figuring out what’s available and what isn’t at boot time, now that many more processes are started form launchd.

I’ll report back with any problems I’m sure to encounter migrating my startup scripts to launchd in Leopard.

The DVD drive on my desktop Mac is broken, making it difficult to install the operating system. I wanted to put Leopard on this machine today, so I tried installing to the machine from my MacBook Pro.

Since Leopard is now Universal for both PowerPC and Intel, this ended up working nicely. The one note, however, is that installer will complain about the partition table when it’s executing on an intel machine, but installing to a PowerPC disk. The installer thinks it’ll be booting from the drive, so it doesn’t like the Apple Partition Map, demanding a GPT table instead.

The solution is to set the CM_BUILD variable, allowing installation to the target disk.

  export CM_BUILD=CM_BUILD
  export COMMAND_LINE_INSTALL=1
  export SRC="/Volumes/Mac OS X Install DVD"

  installer -verbose \
    -pkg "$SRC"/System/Installation/Packages/OSInstall.mpkg \
    -target "/Volumes/Macintosh HD 1/" \
    -lang en | tee /tmp/installer.log

One of the small, but incredibly useful features for me in Leopard is that ssh-agent is automatically running for each user account. This relatively small change allows me to log into remote machines without entering my password each time.

Using the SOCKS proxy built into ssh, we’re also able to setup a quick and easy secure tunnel. I wanted to check some sensitive information this morning, but I’m at a coffee shop that doesn’t pass VPN traffic, so I quickly hacked together the following:

Setup a new Location in the Network System Preference Pane to configure the SOCKS proxy at 127.0.0.1, port 4088. This connects most Apple applications to the secure and encrypted tunnel.

Next, I configured ssh to automatically setup the SOCKS proxy whenever I type “ssh ford”, which is an alias for my workstation back at the office.

# ~/.ssh/config
host ford
  User mccune
  HostName ford.math.ohio-state.edu
  # Handle sleep/wake robustly with TCPKeepAlive
  TCPKeepAlive no
  Port 22
  # DynamicForward is a SOCKS proxy server.
  DynamicForward 4088
  ForwardX11 no

With this configuration, I’m able to load my SSH public key into the ssh-agent running by default on Leopard, type “ssh ford” to setup the encrypted SOCKS proxy, then change location to “SSH Socks Proxy” to automatically have Mail.app, iChat, Safari and Camino use the secure proxy.

An easy way to verify the proxy is working is to add an IP Address gadget to your personal google home page:

Finally, with the Network Location module for Quicksilver, you can easily switch back and forth between the encrypted proxy.

I quickly noticed that the “mate” command line tool does not work as expected under GNU Screen on Leopard. The error I get is:

mate: failed to establish connection with TextMate.

I suspect this is a side-effect of the Leopard sandbox feature. I’ve found a quick shell alias to be a nice work-around:

alias mate='open -a TextMate.app'

This works inside of GNU Screen, where the mate command line utility does not.

So I’m finally running Mac OS X 10.5 Leopard on my portable. I’ve decided to migrate to the new sparsebundle style FileVault image, and here’s how I did it:

First, make sure you’ve created a FileVault master certificate by setting a master password in the Security preference pane.

Manually create the sparse bundle:

umask 077
export NAME="mccune"
hdiutil create -size 300g \
  -encryption -agentpass \
  -certificate /Library/Keychains/FileVaultMaster.cer \
  -uid 502 -gid 20 -mode 0700 \
  -fs "HFS+J" \
  -type SPARSEBUNDLE \
  -layout SPUD \
  -volname "$NAME" \
  "$NAME".sparsebundle;
chown -R "$NAME":staff "$NAME".sparsebundle

Make sure to set the password on the disk image the same as the password used with the user account, otherwise the system won’t be able to decrypt the image from the loginwindow.

Mount the sparsebundle:

hdiutil mount -owners on -mountrandom /tmp -stdinpass "$NAME".sparsebundle

Copy the contents of your home directory:

rsync -avxHE --progress /Users/mccune/ /tmp/dmg.TYSCwg/

After I did the initial pass with rsync, I logged out of my user account, and logged in using the administrator account in order to run the rsync process a second time, while my profile was in a steady state.