Apple Software Updates With Munki
Pages 93
- Home
- Adobe CS5 Update Dependencies
- Adobe CS6 Products
- Adobe Flash Player
- Adobe Reader
- App Dmg Package Notes
- App Store Apps
- Apple Software Updates With Munki
- Blocking Applications
- Bootstrapping With Munki
- Building Munki
- Building Munki2 Pkgs
- ChoiceChangesXML
- Client Customization
- Common Munki Setups
- Conditional Items
- CopyFromDMG
- Creating Disk Images
- Custom Help Content
- Demonstration Setup
- Discussion Group
- Documentation Ideas
- Dynamic Client Configurations Via Preflight Scripting
- Execute Munki With a LogoutHook
- FAQ
- GarageBand
- Glossary
- Google Code Wiki to Github Wiki Guide
- How Munki Decides What Needs To Be Installed
- Installing On Standalone Machine
- Installing OS X
- Known Issues and Workarounds
- Launchd Jobs and Changing When Munki Runs
- License Seat Tracking
- Localization Maintenance
- Makecatalogs
- makepkginfo
- managedsoftwareupdate
- Managing Admin Rights With Munki
- Managing Configuration Profiles
- Managing Printers With Munki
- Manifests
- manifestutil
- MCX Support In Munki
- Middleware
- More Links And Tools
- MSU Logging
- Munki And Acrobat 9 Pro
- Munki And Adobe CC
- Munki And Adobe CS3
- Munki And Adobe CS4
- Munki And Adobe CS5
- Munki And Adobe CS5 Updates
- Munki And Adobe CS6
- Munki And AdobeCS5
- Munki And AdobeCS5 Updates
- Munki And AdobeCS6
- Munki and AutoRemove
- Munki And Office 2008
- Munki And Office 2011 Updates
- Munki and Office 2016
- Munki Configuration Script
- Munki Dev Support
- Munki Links
- Munki With Git
- Munki2 Introduction
- munkiimport
- On Demand Items
- Overview
- Pkginfo Files
- Pkginfo For Apple Software Updates
- Pre And Postinstall Scripts
- Preferences
- Preflight And Postflight Scripts
- Product Icons
- Professional Support
- Release Notes
- Removing Munki
- Repackaging
- Report Broken Client
- Road Map Discussion
- Screenshots In Product Descriptions
- Supported Pkginfo Keys
- Troubleshooting
- Updating Munki Tools
- Upgrading To Munki2
- Using Basic Authentication
- Using Munki Catalogs
- Using Munki With SSL Client Certificates
- What Are Stupid Munki Tricks
- Workflow Example
- WPKG like Dynamic Manifests Without CGI
- Xcode
- Show 78 more pages…
Introduction
- Getting Started
- Overview
- Discussion Group
- Demonstration Setup
- Glossary
- Frequently Asked Questions
- Release Notes
New in Munki 2
- Introduction
- Munki Links
- Product Icons
- Screenshots In Product Descriptions
- Client Customization
- Custom Help Content
- Upgrading to Munki 2
Tools
Munki configuration
Manifests
Catalogs
Pkginfo
- Pkginfo Files
- Supported Pkginfo Keys
- Pre And Postinstall Scripts
- Munki And AutoRemove
- Blocking Applications
- ChoiceChangesXML
- CopyFromDMG
- Pkginfo For Apple Software Updates
- Managing Configuration Profiles
- How Munki Decides What Needs To Be Installed
Advanced configuration
- Securing the Munki repo
- Preflight And Postflight Scripts
- Report Broken Client
- MSU Logging
- Munki With Git
- Bootstrapping With Munki
- License Seat Tracking
- LaunchD Jobs and Changing When Munki Runs
- Web Request Middleware
Related tasks
- Repackaging
- Creating Disk Images
- Stupid Munki Tricks
More
- Troubleshooting
- Professional Support
- Known Issues and Workarounds
- Building Munki 2
- Removing Munki
- More Links And Tools
- Munki Configuration Script
Product-specific notes
- App Store Apps
- Adobe Products
- GarageBand
- Microsoft Office
- Xcode
- Installing OS X with Munki
- Updating Munki Tools
Legacy Documentation
Introduction
Munki can be configured to install available Apple Software Updates, with the benefit that users don't need to be administrators to install updates.
Details
To install Apple Software Updates with Munki, set InstallAppleSoftwareUpdates to True in /Library/Preferences/ManagedInstalls.plist:
<key>InstallAppleSoftwareUpdates</key>
<true/>Or using defaults:
defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates -bool TrueYou may also direct Munki to use a different Apple Software Update server (for example, one you host internally) by setting the SoftwareUpdateServerURL key in /Library/Preferences/ManagedInstalls.plist to the appropriate CatalogURL:
<key>SoftwareUpdateServerURL</key>
<string>http://applesus.myorg.org:8088/index-leopard-snowleopard.merged-1.sucatalog</string>or again with the defaults command:
defaults write /Library/Preferences/ManagedInstalls SoftwareUpdateServerURL "http://applesus.myorg.org:8088/index-leopard-snowleopard.merged-1.sucatalog"(Setting this value is not currently recommended under OS X 10.11 El Capitan)
Apple update behavior notes
Munki updates and Apple Software updates can appear and be installed in the same Munki session. To prevent possible conflicts, if any item to be installed or removed from the Munki server is an Apple item, Apple updates will not be processed in the same session. An item from the Munki server is identified as an Apple item if it has the optional apple_item key set toTrue in its pkginfo file.
Additionally, an item will be treated as an apple_item during an update check if the apple_item key is missing but the item contains either a receipts array with a packageid key that starts with com.apple or an installs array with a CFBundleIdentifier key that starts with com.apple.
It is important to note that any Apple application scheduled for install without an apple_item key explicitly set to False will cause the item to be treated as an apple_item during an update check. The implication of this is that if a user has an update waiting to be installed for Pages, as an example, and the Pages update has no apple_item key set no Apple software update checks will be performed for as long as the user postpones the Pages update.
In reality this means that if any high-profile Apple software updates (Security Update, OS X update) became available after the user first received the Pages update they will not be available for install until after Pages is installed. If an important OS X update has also been given a force_install_date by the admin via the apple_update_metadata method and the user doesn't install the waiting Pages until after the forced date expires, before long Managed Software Center will initiate the final one hour grace period countdown and logout to install the waiting Apple update. This may be a problem from a UX point of view and makes directly managing the apple_item key very important in order to prevent long periods of Apple software update "blackout" for users who tend to postpone waiting updates for long periods on end, or any surprises arising from passed forced install deadlines.
In order to prevent such a blackout the admin has two options:
- Mark all Apple updates in Munki as unattended where possible
- Set the
apple_itemkey to<false/>in any Apple item's pkginfo file
For additional notes on the apple_item key see this section of the Munki wiki.
Mavericks+ notes
Due to changes in how the /usr/sbin/softwareupdate tool works in OS X 10.9 and 10.10, you may have unexpected/undesirable results if you use MCX or configuration profiles to manage the CatalogURL in com.apple.SoftwareUpdate. See this discussion: https://groups.google.com/d/topic/munki-dev/fxnOkoweSIo/discussion
As an alternative to managing this preference with MCX or configuration profiles, consider just directly setting your desired CatalogURL in /Library/Preferences/com.apple.SoftwareUpdate.plist.
El Capitan notes
Due to changes in how the /usr/sbin/softwareupdate tool works in OS X 10.11, it is no longer recommended to set SoftwareUpdateServerURL in Munki's preferences. Instead you should just allow Munki to use whatever Apple Software Update is using "normally" -- either the system defaults, or a CatalogURL value set in the com.apple.SoftwareUpdate preferences domain.
With the 2.8.0 release of the Munki tools, the SoftwareUpdateServerURL, if set, will be ignored under 10.11+.
Apple Update Metadata
Munki supports admin-provided additional metadata for Apple updates, which allows admins to better control the timing and conditions of Apple updates. Adding metadata information for an Apple update cannot cause Munki to offer any update Apple Software Update will not offer. It can only change how the update, if available from Apple Software Update, is installed. It can allow Munki to install an Apple update in an unattended manner; it can require a logout or restart even if the update normally would not require these, or it can be force installed after a certain date. Again, if Software Update is not offering the item to the client, Apple Update Metadata cannot force it to do so.
More info on Apple Update Metadata is Pkginfo For Apple Software Updates.
Using the Munki tools only to install Apple Software Updates
You can use the Munki tools without any Munki repository to install Apple updates. In /Library/Preferences/ManagedPreferences.plist, set AppleSoftwareUpdatesOnly to True.
defaults write /Library/Preferences/ManagedInstalls AppleSoftwareUpdatesOnly -bool Truemanagedsoftwareupdate will then not request a manifest and catalog(s) from a Munki server, but will proceed directly to checking for (and possibly installing) Apple Software Updates.
Apple Update Metadata functionality is not available with this configuration, since the additional metadata is stored in a Munki repo.