Undocumented options

Rich Trouton posted today about undocumented options for the asr command-line utility.

On Twitter, Marnin asked:

Lots of OS X utilities have undocumented options. Take for example /usr/sbin/softwareupdate — the command-line Apple Software Update utility.

It’s had several undocumented options for years. Continue reading “Undocumented options”

Undocumented options

Creating Recovery Partitions

Allen Golbig has an article on AFP548 on creating a package that will create or update a Recovery partition on a Lion or Mountain Lion volume.

The solution requires you get a few pieces from Apple:

  1. The BaseSystem.dmg and BaseSystem.chunklist from an InstallESD.dmg; found inside “Install Mac OS X Lion.app” or “Install OS X Mountain Lion.app”
  2. Apple’s Lion Recovery Update package.

Additionally, Allen’s solution requires the use of Joe Block’s The Luggage, which in turn requires Xcode (or at least the Xcode command line tools) and PackageMaker.

Since getting all of that running might be a nasty hurdle to jump for some, I’ve put together a package template you can use. It’s available here.

To use it, you’ll still need to obtain the dmtest tool from the Lion Recovery Update package and the BaseSystem.dmg and BaseSystem.chunklist from an InstallESD.dmg.

pkgutil --expand RecoveryHDUpdate.pkg ./RecoveryUpdate
cd ./RecoveryUpdate/RecoveryHDUpdate.pkg/Scripts/Tools/
cp dmtest /path/to/CreateRecoveryPartition.pkg/Contents/Resources/

hdiutil attach /path/to/InstallESD.dmg -noverify
cp /Volumes/Mac\ OS\ X\ Install\ ESD/BaseSystem.* /path/to/CreateRecoveryPartition.pkg/Contents/Resources/
hdiutil eject /Volumes/Mac\ OS\ X\ Install\ESD/

When you are done, CreateRecoveryPartition.pkg/Contents/Resources/ should contain:


You’re done unless you’d like to edit the package identifier and/or version in CreateRecoveryPartition.pkg/Contents/Info.plist.

You can now use this package to install a Recovery partition (or update an existing partition).

Creating Recovery Partitions

Mountain Lion and Software Update

Mountain Lion introduces a small, yet significant change in how OS X clients communicate with Apple’s Software Update servers.

Mountain Lion clients by default now consult an HTTPS URL to check for updates on Apple’s servers.

This has the implication that you can no longer use DNS trickery with Mountain Lion clients to get them to access your internal SUS instead of Apple’s. Some organizations configured their internal DNS servers to resolve requests to swupdate.apple.com to an internal server.

The appeal of this approach (DNS hijacking) was that you did not need to touch any client machine to get it to use your internal Softwar Update server; any client using your network would “automagically” use your internal Software Update server.

HTTPS connections do certificate verification of the host. Since your internal SUS can’t offer a certificate proving it is Apple’s server (because it’s not!) a Mountain Lion client will refuse to talk to it. (It’s also possible that your internal SUS is not accepting HTTPS connections anyway, but even if you were to turn that on, it would not help.)

HTTPS prevents exactly the sort of DNS impersonation that made this hack work in the first place. Apple has closed that door.

In order to use an internal Software Update server (either Apple’s or Reposado) with Mountain Lion clients, the clients must be explicitly pointed to your internal server via MCX or by setting the preference using:
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL <internalSUScatalogURL>

Mountain Lion and Software Update

Installing Lion and Mountain Lion instead of “Imaging”

Now that you can create an Installer package to install Lion or Mountain Lion, you have the possibility of using this package instead of an “image” to initially setup/configure a machine.

This may not be initially obvious.

If you’ve used InstaDMG or Apple’s System Image Utility to build a deployment image, you might notice that the components you use are very similar to the components you use to create a Lion or Mountain Lion installer package. Those components are:

  1. OS X installation media (usually an InstallESD.dmg)
  2. One or more additional packages to install after the OS is installed.

The difference is that InstaDMG “compiles” those components into a disk image that you “restore” to a target volume. System Image Utility can do that as well, or it can create a NetInstall workflow that just installs the components in order.

An advantage of the “compiled” disk image approach is speed. It’s much faster to restore a disk image to a target volume than it is to install the components seperately.

But there are advantages to the “install the components” approach as well:

  1. You can upgrade or reinstall OS X on a current boot volume without affecting user data. “Imaging” requires erasing the target first.
  2. Installing Lion or Mountain Lion causes the appropriate Recovery HD to be created automatically. If you use an imaging approach, you have create the Recovery HD separately; either by capturing and deploying an image of the Recovery HD, or using another scripted process to create it.
  3. InstaDMG and SIU generally limit you to building an image on the same OS; in other words, you can only build Mountain Lion images on a Mountain Lion machine, and Lion images on a Lion machine. createOSXinstallPkg allows you to create Lion and Mountain Lion installers on Snow Leopard, Lion, and Mountain Lion.

It’s possible to use DeployStudio to install Lion or Mountain Lion on a target volume using a package created by createOSXinstallPkg. You can upgrade an existing volume, or erase and install to an empty disk. Rich Trouton has documented these options:




Installing Lion and Mountain Lion instead of “Imaging”

Mountain Lion and MCX

In my last post, I asserted that Local MCX still works in Mountain Lion. And it does. But that doesn’t mean there aren’t issues to deal with.

There have been various reports of certain MCX settings not behaving correctly — for example, it appears that currently you can’t use MCX to manage Dock settings “Once” — only “Always” management works. (And that’s not useful for us — it doesn’t allow one to set certain Dock defaults and then leave the Dock alone for the user to modify as they’d like.)

There’s another challenge if you use Local MCX in an alternate local DirectoryService node, as described here:

In Mountain Lion, dscl refuses to write to non-default local nodes:

# sudo dscl /Local/MCX create /Computers/foo
create: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)

This makes manipulating things in a non-default local node much harder than it was in Leopard through Lion.

You can still copy files into /private/var/db/dslocal/nodes/MCX, and that can serve as a workaround for now. All of the packages I use to configure Local MCX do exactly that — they install plist files into /private/var/db/dslocal/nodes/MCX/computergroups. But there is one major exception.

I have one package that does the setup for Local MCX. It makes sure the /Local/MCX node is present, makes sure it is in the search path, and makes sure that an appropriate record exists in /Local/MCX/Computers to represent the current local machine. This requires writing to the /Local/MCX node to dynamically create the computer record. We can’t just install a file, because the contents of the data in the computer record are unique for each computer.

So there’s our problem: we can’t use dscl to create a computer record in the /Local/MCX node, yet we must dynamically create an object in that node.

There are two solutions, both which rely on the fact that all objects in Local DirectoryService nodes are actually just plist files.

The first:  We could use another plist creation tool to create the needed plist. We could use defaults or PlistBuddy, for example. But that would require us to take the time to figure out how to use one of those tools to create a file that is the same as if dscl created it.

The second: Use dscl to create the record in the /Local/Default node. Then just move the plist from /private/var/db/dslocal/nodes/Default/computers/foo.plist to /private/var/db/dslocal/nodes/MCX/computers/

The second approach is the one I decided to take, since it seemed easier.

Here is the script I currently use for initial Local MCX setup. If you are currently using Local MCX on Lion or earlier, I hope it is of some help if you want to continue to use Local MCX on Mountain Lion.

Mountain Lion and MCX

Mountain Lion: suppress Apple ID / iCloud prompt

This question has come up a few times in the past few days, so I thought I’d better document it.

On Mountain Lion, how do I suppress the Setup Assistant that prompts for an Apple ID to setup iCloud?

The answer is to use MCX. You can use Local MCX, network directory-based MCX, or Profiles.

You can read more about Local MCX here. (And yes, Local MCX still works in Mountain Lion.)

# dscl /Search mcxread /ComputerGroups/setupassistant
App domain: com.apple.SetupAssistant
Key: DidSeeCloudSetup
State: once
Value: 1

App domain: com.apple.SetupAssistant
Key: LastSeenCloudProductVersion
State: once
Value: 10.8

Here is a profile that will do the same thing. You can use the command-line profiles tool to install it.

NOTE: for whatever reason, this doesn’t work if the management frequency is set to “Always” or “Forced”. It does work when set “Once”. I have not tested “Often”, but I imagine that would work as well.

Mountain Lion: suppress Apple ID / iCloud prompt

Son of InstallLion.pkg

Mountain Lion imageLast fall, I released a set of tools I called “InstallLion.pkg”. The introductory post is here.

Now that Mountain Lion has been released, you may be wondering: “Can I use these tools to create a deployment package for Mountain Lion?” The answer is yes. InstallLion.pkg can be used to make an installer package for Mountain Lion.

But I have a better set of tools for you. Today I’m introducing createOSXinstallPkg. This tool can be used to create installer packages for Lion and Mountain Lion and features many improvements over the “InstallLion.pkg” tools.

The first improvement: it’s much easier to use createOSXinstallPkg to create installer packages. With the old tools, you had to run one or two scripts — one to download an “IncompatibleAppList” package, and one to customize the InstallESD.dmg if you wanted to install additional packages along with the OS X install. And then you had to manually assemble the package, copying several components into the right places within a template package.

With createOSXinstallPkg, it’s as easy as:

sudo ./createOSXinstallPkg --source /Applications/Install\ OS\ X\ Mountain\ Lion.app

to create a basic uncustomized package that installs Mountain Lion.

But wait! There’s more!

Continue reading “Son of InstallLion.pkg”

Son of InstallLion.pkg