NetBoot Part 3

I've become quite the package whiz, if I do say so myself. Actually, I'm probably doing something ass-backwards, but still, I wanted to share some of my working methods as they seem to be, well... Um... Working...

One of the things I'm doing is using packages to run shell scripts that make computer settings (like network settings and user-creation) rather than actually installing files.

PackageMaker: I Prefer the 10.4 Version of Packages
(click image for larger view)

This can be done in PackageMaker by taking some creative liberties with preflight and/or postflight scripts. The only hitch is that PackageMaker insists that you install at least some files onto the target system.

PackageMaker: Installing Scripts to /tmp
(click image for larger view)

So the majority of my packages contain only a single script. That script first gets installed to /tmp, thus fulfilling PackageMaker's "must install files" directive.

PackageMaker: A Postflight Script
(click image for larger view)

The script then runs as a posflight script, and the last line of the script deletes the instance of the script in /tmp, just for good measure.

Shell Script: Removing the Script from /tmp
(click image for larger view)

It could be argued that there's no reason to create packages from scripts, that you could just as easily run the scripts directly in ASR, but packages offer a couple of advantages. For one, packages leave receipts, so it's easy to check and see if something's been set on a computer. For two, packages are easy to deal with; assistants and other SysAdmins know how they work and can easily understand how to use them. Need to change a machine's settings? Don't run a script. Hell, don't even bother opening System Preferences. Just open and run a package. What could be easier (and less error-prone, I might add)? From an ease-of-use perspective, packages have a huge advantage. And ease-of-use adds efficiency. Which is why I not-so-suddenly find myself in the envious position of being able to build systems in about half the time (or less!) it used to take. That's a huge improvement!

Using this method (and sound DNS) I've been able to write packages that configure network settings, create computer-specific users, set custom disk and file permissions, set up autofs, bind to our authentication server and set up SSH for password-less login.

Next on the list: File Sharing!

Should be fun.

Firmware Goodness

I don't usually get too excited about firmware updates, mainly because the things they fix rarely tend to affect me, for whatever reason. But the last Leopard Graphics Update from a few weeks ago has actually caused me some problems. Two, I believe, to be precise.

The first problem I've had may or may not be related to the Leopard Graphics Update: occasionally my machine — my brand new, fresh-out-of-the-box machine — just locks up, requiring a force reboot. I don't remember where, but I do remember reading that people were associating this with the Leopard Graphics Update, and it definitely started happening to me immediately after that update, so I'm fairly sure the update was the cause. The second problem has been cosmetic: when typing in the Spotlight menubar the drop-down sheet flickers in and out, causing a really annoying strobe effect until the window stops updating. Very irritating!

The good news is, Apple's latest ATI Radeon HD 2600 XT Firmware Update fixes the second problem. Here's hoping it fixes the first one as well. Only time will tell.

UPDATE 3-28-07:
Yep. All fixed. Since applying this update my machine has not locked up. Nice.

Secondary DNS Configuration

I recently had occasion to do some Mac OS X DNS configuration. Primary DNS setup is pretty straightforward, but I always get stuck on the secondary DNS config, and this week I had the (not so) rare privilege of discovering I'd been doing it wrong all along. I thought I'd post some quickie instructions for next time this comes up.

So, to set up your Mac OS X Server as a secondary DNS server (that is, if the primary goes down, this one will act as a failover), you'll need to open Server Admin and navigate to the DNS section (we'll use the 10.4 version, but the basic gist is the same in 10.5). Next, add a secondary zone under "Secondary Zones." This first one will be for your forward lookups. In the first field add the full name of your zone. In the second field add the IP address of your primary DNS server. It should look like this:

Secondary DNS: Forward Lookups
(click image for larger view)

Now add another secondary zone for the reverse lookups. This is exactly the same except that instead of the zone name in the first field, you'll use the reverse zone information. It looks like this:

Secondary DNS: Reverse Lookups
(click image for larger view)

Note that the reverse IP in the field should cover the zone IP range. That is, if your primary DNS server covers "192.168.1" zone, you'll enter the reverse info for that range. If your primary DNS covers all of "192.168" (notice the truncated IP number) then you should enter that. All together it should look like this:

Secondary DNS: All Together Now
(click image for larger view)

Once this is all set up and saved, you can start the service. You can tell it worked by listing the contents of /var/named. You should see two new files, one called your.domain.com.bak and one called your.IP.in-addr.arpa.bak. And these should be populated with the same DNS info as your primary.

And that's it! Enter the new secondary DNS server info in your Network System Preferences, just after the primary, and if your main DNS fails you'll be covered.

Oh, almost forgot, thanks to this dude for helping me figure all this out.

Leopard Installer Certificates

If you've been using Software Update (like I have, up 'til the other day), you've probably missed one of the new features of Leopard: Installer Certificates. Major updates from Apple now come with certificates of authenticity.

So, for instance, download the standalone Mac OS X 10.5.2 installer and launch the package in the Installer application, and you'll notice a small, new certificate badge in the upper right hand corner of the installer window.

Apple Installer: Certificate Badge
(click image for larger view)

Click the badge and you can take a look at the certificate that's attached to the installer, replete with details about said certificate under the "Details" disclosure triangle.

Apple Installer: Certificate Details
(click image for larger view)

It's another preemptive step in the right direction, security-wise. Always nice to see.

NetBoot Part 2

So here's the plan, as it stands right now. (Yes, I have a plan already! Yes, that was quick.) First, build an image that's good for all workstations (laptops, staff machines, standard workstations, etc.) throughout the lab with:

• Base OS (Mac OS X Leopard 10.5)
• A DHCP network connection
• Apple applications
• Adobe applications
• Drag-and-drop applications
• Other third-party applications
• One admin user
• ARD active

IMAGE THIS SYSTEM
This becomes the base system build, the Master Image — the replacement system if a machine ever needs rebuilding. It is the only full system image. There is only one.

Everything else that is machine-type specific — that is, users, applications, application components, crontabs, anything — gets turned into and installed via either a downloaded or hand-rolled package. So far I've been using Apple's PackageMaker, which has matured a great deal since last I tried it. It's pretty nice. I'm also taking a look at Iceberg, which also looks to be pretty full-featured and nifty.

Iceberg: by White Box

(click image for larger view)

PackageMaker: by Apple
(click image for larger view)

These packages can be machine-type specific and stored in a simple folder hierarchy by machine type — laptop packages in the laptops folder, etc. — for organizational purposes. In addition to being machine-type specific, packages can also, I believe, be machine specific. That is, I think we can make settings like computer name and network settings using packages as well. So what we're talking about here is a system of computer building that happens completely over the network, and that can be directed almost entirely from one ARD-toting computer, that computer being mine, of course. (I've always said, the sign of a good SysAdmin is that he never leaves his chair.)

I've gotten pretty good at making application packages, at this point (not that it's terribly hard, mind you). My next step will be to learn how to make system settings with packages as well. My other next step is going to be, of course, creating the Master Build. None of this building happens 'til summer. But still, something tells me it's going to be smart to start this process now and see what crops up over the next couple of months.

As usual, I'll be reporting any new and/or interesting developments.

Oh, and thanks to everyone who commented on the last post. The comments were extremely useful!