Relevant mostly to OS X admins
When I get a new Mac in the office, it goes directly to my no-imaging workflow: NetBoot it to DeployStudio, and run my 10.8 Out Of Box workflow, which names the machine, binds to AD, runs configuration scripts, installs software, and even installs software that installs more software- Munki. I’ve got this workflow down, and I’ve run it dozens and dozens of times.
But yesterday was different: I took a 15″ retina (refub, like most we get) out of the box, NetBooted to DS, ran the workflow, and ran out for an errand, thinking my automated steps would be working in my absence. When I returned, I first noticed the login screen wasn’t right for a machine that had local accounts made, but was waiting for me to properly categorize it in Profile Manager. I tried the administrator account that should work, but it was instantly rejected. Reboot didn’t change things.
I ran the Out Of Box workflow again, this time watching it. After doing all the expected copying and a reboot, it never went into ds_finalize- it just skipped straight to loginwindow. I inquired in the ever-useful ##osx-server channel on IRC if anybody had experienced this, and Rich Trouton suggested starting over, via Internet Recovery reinstall. I did that, got the same results on the initial DS run.
After that, I took out the even more nuclear option: boot from recovery partition, use Disk Utility to erase the main volume, Internet Recovery, then run my Out Of Box DS workflow: success.
During my analysis of the failed runs, I found that only one of the LaunchDaemons was being made, along with just one of the scripts they call. I don’t have an understanding why it worked out this way, but know that a full nuke (not just reinstall) was the only fix I found. I’d be willing to dig more, but of course, the setup was for a new hire starting the next day…
EDIT: I returned to use DS the next day on a different machine, and found the same errors- ds_finalize was never kicking in. I ended up discussing the experience in the DeployStudio forums, and found that the DS folks has been aware of it, and had released an update, without upping the version number. That update fixed things.
One of the projects I’m starting in early 2013 is to get all of the OS X machines I manage at work on Mountain Lion. In my upgrade testing, I found that a machine upgraded from 10.6 would not properly run the NetExtender VPN client from SonicWall- on first use, a user would get interrupted with this alert in a log window:
01/28/2013 12:55:00.545 [general fatal 508] FATAL: You don't have permission to read/execute '/etc/ppp/peers' 01/28/2013 12:55:00.546 [general error 508] pppd permissions are invalid 01/28/2013 12:55:00.554 [gui info 508] Failed to connect - check log for details
I can’t expect my users to tweak permissions on /etc/ppp/peers, and through previous upgrades, I’d also become aware that the NetExtender releases through 6.0.726 have DNS issues under Mountain Lion, so I also I needed to both upgrade, and tweak ppp permissions.
At first, the upgrade side would look simple, NetExtender installer provides an app to drop into /Applications. But if one only does that, they get this dialog on first launch:
That’s not going to fly for my non-admin users (nor should I expect my admins to do this), so I turned to JAMF’s Composer to repackage. The process was pretty simple- I copied the latest NetExtender .dmg and Composer to a basic OS X build, which had never had NetExtender installed. I copied NetExtender to the Applications folder, then started Composer, selecting a new Snapshot, by monitoring file system changes.
After starting up the monitoring, I started up NetExtender, provided the expected authentication, let it connect, and then ended the Composer capture. The capture then only needed a little tweaking to omit the changes to my home directory that had been noted, and created via Build as PKG.
#!/bin/sh chmod u+s /usr/sbin/pppd exit 0
My 10.6 to 10.8 upgrades are running a number of steps via a second DeployStudio workflow, done after the install, as we’re changing machine naming and AD bind conventions, doing a Profile Manager enrollment, and many other steps. To force a reinstall of NetExtender, I added a DS “generic” workflow step that includes rm -r /Applications/NetExtender.app, and touch /Users/Shared/ .com.googlecode.munki.checkandinstallatstartup file, forcing Munki to see that NetExtender is absent, and run the installer again to adjust the permissions.