Rich Trouton posted today about undocumented options for the asr command-line utility.
On Twitter, Marnin asked:
.@rtrouton The question is what other commands have hidden options?
— Marnin (@gmarnin) April 30, 2013
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”
FileWave has introduced a free new tool for creating compiled OS X images: Lightning.
Though they position it as a tool to help with Thunderbolt/Firewire imaging, it actually is a more general purpose tool. My initial impression is that if you are building compiled Lion or Mountain Lion images, this tool could replace the use of InstaDMG or System Image Utility for many people.
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:
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:
BaseSystem.chunklist
BaseSystem.dmg
dmtest
en.lproj/
package_version
postflight
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).
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>
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:
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:
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:
http://derflounder.wordpress.com/2011/09/08/upgrading-to-lion-with-deploystudio/
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.
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.
Last 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!
Managing OS X 