When the “Install Mac OS X Lion” application runs, it queries Apple’s Software Update servers and downloads a package named “MacOS_10_7_IncompatibleAppList.pkg” and copies it and an “index.sproduct” file that lists this package to the “Mac OS X Install Data” directory as part of the preparation for installing Lion.

This package updates a list of software that is incompatible with Lion by updating “English.lproj/IncompatibleApplicationsStrings.strings” and “MigrationIncompatibleApplicationsList.plist”
inside /System/Library/PrivateFrameworks/SystemMigration.framework/Versions/A/Resources/.

Updating this list of incompatible software does not seem to be vital to the installation of Lion. The index.sproduct file must exist, however, or the automated install is aborted. If you do not include the MacOS_10_7_IncompatibleAppList.pkg and index.sproduct files inside the InstallLion.pkg, the postflight script will create an “index.sproduct” file containing an empty “Packages” array.

Still, it’s probably a good idea to include the current version of the MacOS_10_7_IncompatibleAppList.pkg in your InstallLion.pkg if possible.

I’ve provided a tool to help you download the current version of the incompatible app list package. It’s named “getIncompatibleAppListPkg”. It will download the MacOS_10_7_IncompatibleAppList.pkg and create an index.sproduct file, saving both in the current directory. They must be copied to the InstallLion.pkg/Contents/Resources/Mac OS X Install Data/ directory.

Here’s a sample execution of the tool:

% ./getIncompatibleAppListPkg
Downloading http://swcdn.apple.com/content/downloads/02/12/041-1997/jPTmxRrfybSnP8NTRfwggvDn4F9byWBgvd/MacOS_10_7_IncompatibleAppList.pkg...
Writing index.sproduct...
Done.


You’d find MacOS_10_7_IncompatibleAppList.pkg and index.sproduct in your current working directory; you would then copy them to InstallLion.pkg/Contents/Resources/Mac OS X Install Data/

(Note: I found also that I could not add arbitrary packages to the Packages array of index.sproduct; the OS X Installer skipped any packages that were unsigned. Therefore the index.sproduct file is not easily used to install additional arbitrary packages. I was unwilling to go through the effort to convert my additional packages to “flat” packages and sign them to do further testing.)

Documentation:
http://installlionpkg.munki.googlecode.com/git/README.txt

Zip archive:

http://munki.googlecode.com/files/InstallLionPkg.zip

Clone the Git repo:

git clone https://code.google.com/p/munki.installlionpkg/

Enjoy! Feedback and discussion should be directed to the munki-dev list at http://groups.google.com/group/munki-dev/

Munki is a set of tools that manages software installs, removals and updates for Mac OS X machines.

This release incorporates the latest Apple Software Update code, which addresses all of the known issues with Munki’s handling of Apple software updates, and adds new support for force_install_after_date for installs.

See this document for more info about this feature.

Download the preview release here.

Some earlier posts on Local MCX:

• http://managingosx.wordpress.com/2010/03/12/yet-again-with-the-local-mcx/
• http://managingosx.wordpress.com/2010/03/07/local-mcx-update/
• http://managingosx.wordpress.com/2010/03/07/mcx-in-non-default-local-nodes/
• http://managingosx.wordpress.com/2008/02/07/mcx-dslocal-and-leopard/

The answer is yes – Local MCX works in Lion. There is one minor issue, though: if you are putting your local MCX version in an alternate local directory node (like /Local/MCX), you’ll need to know that Lion is a bit pickier about the contents of the directories of alternate local nodes.

If opendirectoryd on Lion doesn’t like your MCX node, it might look something like this:


> dscl /Local/MCX list /
Data source (/Local/MCX) is not valid.


It turns out this is pretty easy to remedy: Lion’s opendirectoryd requires that a local directory node have at the minimum a “users” and a “groups” subdirectory. So if either of these subdirectories are missing, simply create them and restart opendirectoryd (killall opendirectoryd). dscl should now recognize the node:


> mkdir -p /private/db/dslocal/nodes/MCX/users
> mkdir -p /private/db/dslocal/nodes/MCX/groups
> killall opendirectoryd
> dscl /Local/MCX list /
AFPUserAliases
Aliases
Automount
AutomountMap
ComputerGroups
ComputerLists
Computers
Config
Ethernets
Groups
Hosts
Mounts
NetGroups
Networks
People
PresetComputerGroups
PresetComputerLists
PresetComputers
PresetGroups
PresetUsers
Protocols
RPC
Services
SharePoints
Users


I’ll be speaking in the IT Track on Reposado, a open-source substitute for Apple’s Software Update service, released by Walt Disney Animation Studios.

Early bird pricing ends very, very, soon. Register now!

PS — though I’m not presenting on Munki, I’ll be more than happy to talk to folks informally about it. Justin McWilliams and John Randolph will be presenting on Simian, Google’s open source server that builds on the Munki client tools for maximum scalability!

My series of MacTech articles on Munki are available in MacTech’s online archive:

• Part 1
• Part 2
• Part 3
• Part 4

This week Apple released the MacBook Pro EFI Firmware Update 2.1 and the Thunderbolt Firmware Update 1.0.

Based on past experience, I expected to have to install these manually: launching the updater, shutting down, then holding the power button to get into “firmware update mode”…

Imagine my surprise when:

• Munki downloaded and installed the EFI Firmware update
• Munki rebooted the MacBook Pro
• The EFI firmware updated automatically(!)
• The machine rebooted again.
• Munki downloaded the Thunderbolt Firmware Update
• Munki rebooted the MacBook Pro
• The Thunderbolt firmware updated automatically(!)
• The machine rebooted again.
• The machine came up normally and ready to use.

Completely automatic firmware updates. Is this a first, or did I miss something?

DisableFlash10AutoUpdate-1.0.pkg.dmg

This package installs a file at /Library/Application Support/Macromedia/mms.cfg with the following contents:

AutoUpdateDisable=1

More info here:

http://kb2.adobe.com/cps/167/16701594.html
http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html

Thanks to Patrick Fergus for the tip.

Reposado eliminates the need for Mac OS X Server (and Apple hardware) to host an internal Apple Software Update service. Reposado, a set of tools written in Python, replicates Software Update catalogs and updates. You can then use any available web server to serve these to your clients.

Additionally, Reposado allows you to easily implement an unstable/testing/release workflow, where you release updates only to a small set of machines for testing before releasing the updates to the rest of your managed machines.

Finally, Reposado allows you to continue offering “deprecated” updates. When Apple releases a new version of iTunes or Safari or a new Snow Leopard update, previous updates are no longer available from Apple’s update servers. But with Reposado, you can continue to offer these “deprecated” updates to your machines until you’ve tested the new versions.

Reposado is hosted on GitHub here.
The mailing list is here.

http://forums.adobe.com/message/3600789#3600789

However, like prior releases, Adobe doesn’t make it easy to deploy. Fortunately, this technique still works.

You’ll need:
The package wrapper.
The updated Adobe AIR Installer. Make sure to extract it from the disk image before adding it to the package wrapper.
The updated AdobeHelp.air app. (Adobe doesn’t make that easy to find!)

Follow the instructions from the prior post, and don’t forget to bump the CFBundleShortVersionString in the Info.plist to “3.5.0.23″.

Good luck!