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.

Nigel has posted slides from our Macworld 2008 presentation on Puppet.

Please see: Puppet Macworld 2008 Project

I’ll post additional information once I find out the details of distribution of any audio/video recordings taken during the presentation.

I picked up a 250 Gig Western Digital Passport portable hard drive to keep a backup copy of my file vault home directory, among other things while I travel next week, in the somewhat-likely event something disastrous happens to my laptop.

I really like how small and portable the drive is, along with it’s USB bus powered interface. There’s no futzing around with wall warts and power supplies, it truly is plug and play.

I also really like that my PS3 recognizes the device, since I’ve transfered my entire iTunes library over to it (Huzzah, Option-Starting iTunes to select a library!). All of my H.264 AVC movies play right off of the drive on my Playstation 3 as well, which is really nice and convenient.

Copying some rather large files, specifically a 7 gig ASR Golden Master image of my demonstration PowerBook leopard OS, and the actual Leopard ISO image itself, I ran into a file size limitation of FAT32. Of course, I knew FAT32 didn’t support large files, but I’ve just been spoiled in recent years by things like this “just working.”

I didn’t want to reformat the small drive, because that would surely mean my Playstation 3 would no longer recognize the file system, so instead I opted to create a sparsebundle HFS+ formatted disk image, exactly like I would do manually for Leopard File Vault images.

The end result is that each “band” in the sparse bundle image will satisfy the limitations of FAT32, while providing a nice, secure and robust HFS+J file system to store all of the “big files” I need to carry with me.

Long live robust Disk Imaging Frameworks.

The only catch is that these files are only accessible on Mac OS X Leopard machines now, but that’s not a huge problem for me. Especially traveling to the MacWorld conference.

I usually compute with n-tupel of Mac computers sitting in front of me. I have a strong aversion to clutter, despite the state of my apartment, and the power of Teleport providing seamless, encrypted keyboard sharing, a-la so called “soft KVM” utilities is a killer app for me.

Alas, I’ve found that Teleport does not work as expected when operating from an NFS Mounted Home Directory.

Trying to connect to my Laptop, nutburner (Yes, nutburner is the given name of my first generation MacBook Pro), I received the following error.

UNKNOWN wants permission to sign using key “privateKey” in your keychain. Do you want to allow this?

On a working host, e.g. two machines with file vault home folders, that “UNKNOWN” will actually display as “teleportd”. I suspect whatever logic Apple is using to verify the authenticity of program binaries doesn’t work as expected over NFS.

After clicking “Always Allow” twice, I get the following error:

I synchronize my login.keychain, so the private key and certificate are identical between these two hosts, leading me to believe a certificate algorithm mismatch is unlikely.

In any event, my solution was to simply redirect the teleport.prefPane to a local HFS+ volume using a symbolic link.

# /Scratch is a local HFS+ volume.
mkdir -p /Scratch/mccune/Library/PreferencePanes
mv ~/Library/PreferencePanes/teleport.prefPane \
  /Scratch/mccune/Library/PreferencePanes/
ln -s /Scratch/mccune/Library/PreferencePanes/teleport.prefPane \
  ~/Library/PreferencePanes/teleport.prefPane

Once teleport.prefPane resided on a local HFS volume, everything “just worked” perfectly.

As an alternative, you could deploy the prefPane to /Library/PreferencePanes to make teleport available to all users of the system.

I haven’t posted in awhile, mainly because I’ve been preoccupied with a relatively long and relaxing vacation over the winter break where I largely ignored all things technology.

I’ve been preparing for Macworld 2008, where Nigel Kersten and I will be presenting some demonstrations and technical details about our respective Puppet deployments at Google and Ohio State University.

If you’ll be attending Macworld, feel free to follow my Twitter feed. I don’t post much at the moment, though I believe it’ll really come in handy during the fast and furious pace of a week long conference like Macworld.

Some other links for gratuitous self promotion:

• IT824 Mac OS X Laptop Deployments with Puppet
• My Macworld Social Network Profile
• Macworld 2008 Puppet Site(Check here after Thursday’s Session.)

Please leave a comment if you’ll be attending Macworld this year.

I had $15 in expiring gift cards from when I bought my new TV, so I decided to pick up an inexpensive 2gig Flash drive online.

To increase my peace of mind, I decided to store everything important to me in an encrypted disk image on the device. I used the same method I use to create a FileVault image, and then just moved the image file over to the flash disk.

I’ve been really happy with the performance, and it’s great know that WHEN I lose this tiny thing, none of my private and very sensitive information will be accessible to whoever picks it up.

In addition, there’s really no additional barriers to using this encrypted disk image. I store the password to the disk image in my Keychain, and it’s also encrypted with the FileVault Master certificate as an added layer of protection against forgetting my password.

Finally, even though the following command creates a sparse bundle capable of storing 300 Gigs of data, the Finder will realize the image file lives on a 2 Gig flash drive, and will only display the free space available on the “parent” filesystem.

The command to create the Leopard-only disk image is:

umask 077
export NAME="secure"
hdiutil create -size 300g \
    -encryption -agentpass \
    -mode 0700 \
    -fs "HFS+J" \
    -type SPARSEBUNDLE \
    -layout SPUD \
    -volname "$NAME" \
    "$NAME".sparsebundle;

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.

Here’s a quick script I cooked up to turn off the blinding light that is my iMac display when I go to bed at night.

Features:

• Runs great from Quicksilver.
• Talks to you. (May not be a feature.)
• Doesn’t require administrative rights.

  #!/bin/bash
  # Jeff McCune 
  export CURRENT_DELAY=$(pmset -g | grep displaysleep | awk '{print $2}')
  # Charger or Battery Flag.
  pmset -g | grep -q '^AC.*\*' && export MODE="-c" || export MODE="-b"
  say "The display will shut off in about 90 seconds" &
  # force allows this to work for non-admin users.
  pmset force $MODE displaysleep 1
  # Quicksilver blocks until script completion.  Fork off the reset command.
  bash -c 'sleep 120; pmset force $MODE displaysleep $CURRENT_DELAY' &
  exit 0

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.