-
Notifications
You must be signed in to change notification settings - Fork 339
Pkginfo Files
Details on the format of pkginfo files
Much (most?) of the stuff Munki can do is because of the package metadata made available through the catalogs, which are in turn made from data in pkginfo files. Pkginfo files can be generated with the makepkginfo tool, though they are more commonly created as a side-effect of running munkiimport.
It's important to remember that Munki clients never use pkginfo files directly -- they only query catalogs. Catalogs are constructed from pkginfo files. Therefore, any changes to pkginfo files (adding a new one, deleting one, or editing one) require rebuilding the catalogs using the
makecatalogstool.
Though some of the information in a pkginfo file can be gleaned from the packages themselves, admins can and should add additional information (and sometimes correct the autogenerated info!).
See Supported Pkginfo Keys for an exhaustive list of valid pkginfo keys.
Here's an example pkginfo file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>name</key>
<string>ServerAdministrationSoftware</string>
<key>version</key>
<string>10.5.5</string>
<key>description</key>
<string>Administration tools for OS X Server</string>
<key>display_name</key>
<string>Server Administration Software</string>
<key>installs</key>
<array>
<dict>
<key>type</key>
<string>application</string>
<key>path</key>
<string>/Applications/Server/Server Admin.app</string>
<key>CFBundleIdentifier</key>
<string>com.apple.ServerAdmin</string>
<key>CFBundleName</key>
<string>Server Admin</string>
<key>CFBundleShortVersionString</key>
<string>10.5.3</string>
</dict>
<dict>
<key>type</key>
<string>application</string>
<key>path</key>
<string>/Applications/Server/Workgroup Manager.app</string>
<key>CFBundleIdentifier</key>
<string>com.apple.WorkgroupManager</string>
<key>CFBundleName</key>
<string>Workgroup Manager</string>
<key>CFBundleShortVersionString</key>
<string>10.5.5</string>
</dict>
</array>
<key>receipts</key>
<array>
<dict>
<key>packageid</key>
<string>com.apple.pkg.ServerAdminTools</string>
<key>version</key>
<string>10.5.3.0</string>
</dict>
<dict>
<key>packageid</key>
<string>com.apple.pkg.ServerSetup</string>
<key>version</key>
<string>10.5.3.0</string>
</dict>
</array>
<key>minimum_os_version</key>
<string>10.5.0</string>
<key>installer_item_location</key>
<string>apps/ServerAdminToold1055.dmg</string>
<key>uninstallable</key>
<true/>
<key>uninstall_method</key>
<string>removepackages</string>
</dict>
</plist>Let's tear it apart:
<dict>
<key>name</key>
<string>ServerAdministrationSoftware</string>
<key>version</key>
<string>10.5.5</string>
<key>description</key>
<string>Administration tools for OS X Server</string>
<key>display_name</key>
<string>Server Administration Software</string>name, version, and description should be easy to understand. display_name is an optional key, used to provide a "pretty" display name in the ManagedSoftwareUpdate app.
<key>installs</key>
<array>
<dict>
<key>type</key>
<string>application</string>
<key>path</key>
<string>/Applications/Server/Server Admin.app</string>
<key>CFBundleIdentifier</key>
<string>com.apple.ServerAdmin</string>
<key>CFBundleName</key>
<string>Server Admin</string>
<key>CFBundleShortVersionString</key>
<string>10.5.3</string>
</dict>
<dict>
<key>type</key>
<string>application</string>
<key>path</key>
<string>/Applications/Server/Workgroup Manager.app</string>
<key>CFBundleIdentifier</key>
<string>com.apple.WorkgroupManager</string>
<key>CFBundleName</key>
<string>Workgroup Manager</string>
<key>CFBundleShortVersionString</key>
<string>10.5.5</string>
</dict>
</array>The (optional) installs key is interesting. This must be created by the administrator. It is a list of dictionaries; each dictionary item describes something that is installed by the installation package. Currently supported items:
<dict>
<key>type</key>
<string>application</string>
<key>path</key>
<string>/Applications/Server/Workgroup Manager.app</string>
<key>CFBundleName</key>
<string>Workgroup Manager</string>
<key>CFBundleIdentifier</key>
<string>com.apple.WorkgroupManager</string>
<key>CFBundleShortVersionString</key>
<string>10.5.5</string>
<key>minimum_update_version</key>
<string>10.0</string>
</dict>Munki looks for the application at the specified path. If no path is specified, Munki will look for any installed application with a matching CFBundleName or CFBundleIdentifier. Once found, the application's version is compared to CFBundleShortVersionString. All of these values (CFBundleName, CFBundleIdentifier, and CFBundleShortVersionString) can be found in an application's Contents/Info.plist.
If (optional) minimum_update_version is supplied, only installed versions of the app of version # >= minimum_update_version will be matched.
<dict>
<key>type</key>
<string>bundle</string>
<key>path</key>
<string>/Applications/Server/Server Assistant.app/Contents/Plug-ins/BackupServer.bundle</string>
<key>CFBundleShortVersionString</key>
<string>10.5.1</string>
<key>minimum_update_version</key>
<string>10.0</string>
</dict>A more generic bundle comparison, this time found by path. If the bundle is found at the given path, the CFBundleShortVersionString is compared with the CFBundleShortVersionString in bundle's Contents/Info.plist.
Once again, if (optional) minimum_update_version is supplied, only installed versions of the bundle of version # >= minimum_update_version will be matched.
<dict>
<key>type</key>
<string>plist</string>
<key>path</key>
<string>/Applications/Server/Server Admin.app/Contents/Info.plist</string>
<key>CFBundleShortVersionString</key>
<string>10.5.3</string>
<key>minimum_update_version</key>
<string>10.0</string>
</dict>A generic plist comparison which might be useful for Info.plists or version.plists in odd locations.
Once again, if (optional) minimum_update_version is supplied, only installed versions of the plist of version # >= minimum_update_version will be matched.
<dict>
<key>type</key>
<string>file</string>
<key>path</key>
<string>/var/db/b.receiptdb</string>
<key>md5checksum</key>
<string>375bb4dca4624474019338a5c1246f82</string>
</dict>The attribute path is checked for existence. If the key md5checksum exists, the checksum of the file on disk is compared with the provided checksum.
The easiest way to create the installs item keys is using the makepkginfo tool, and providing paths to the items:
makepkginfo /path/to/TextWrangler.pkg.dmg -f /Applications/TextWrangler.app
Back to the original catalogitem:
<key>receipts</key>
<array>
<dict>
<key>packageid</key>
<string>com.apple.pkg.ServerAdminTools</string>
<key>version</key>
<string>10.5.3.0</string>
</dict>
<dict>
<key>packageid</key>
<string>com.apple.pkg.ServerSetup</string>
<key>version</key>
<string>10.5.3.0</string>
</dict>
</array>receipts is a list of packageids installed by the installer item. The tool does its best to figure out what packageids are in a given installer item.
receipts are used two ways:
- If there is no installs key, catalogcheck uses the receipts list to determine if a given item is installed or not.
- If the package is marked as uninstallable and the uninstall method is removepackages, this is the list of packages to remove.
Returning to the catalogitem:
<key>minimum_os_version</key>
<string>10.5.0</string>When managedsoftwareupdate is looking for valid items to install, it checks the OS version of the current machine against this key. installitems that require a later OS version than the OS on the current machine are skipped. Note this can cause errors in the log if a manifest refers to "MyGreatApp" for a machine, but all the pkginfo items for various versions of "MyGreatApp" require a later version of the OS than the current machine. managedsoftwareinstall will complain that it cannot find info for MyGreatApp.
maximum_os_version can also be specified, using the same format as minimum_os_version.
<key>installer_item_location</key>
<string>apps/ServerAdminToold1055.dmg</string>This is the relative path to the installer item on the repo web server.
<key>uninstallable</key>
<true/>
<key>uninstall_method</key>
<string>removepackages</string>
</dict>
</plist>These optional keys determine if ManagedInstaller can attempt to uninstall this item. Supported uninstall_methods include removepackages and a full path to an executable script that does the uninstall, for example from the catalogitem for XcodeTools:
<key>uninstallable</key>
<true/>
<key>uninstall_method</key>
<string>/Developer/Library/uninstall-devtools</string>You may also specify "uninstall_script" as the uninstall_method; in that case you must supply the uninstall_script as the value of the "uninstall_script" key.
There are two kinds of dependency/relationship keys, which define how various install items are related to each other. This provides a mechanism for munki to automatically discover related items without the admin having to explicitly include one or many of them in a manifest, as long as munki has the related item in an accessible catalog.
requires are prerequisites: package B requires package A be installed first. Package A may be in the manifest, but only its inclusion in a catalog accessible from the intended computer is needed. If package B is removed, package A is unaffected.
The requires key has an array as its value, as a given item could require multiple items to be installed first.
<key>requires</key>
<array>
<string>XcodeTools</string>
</array>With requires, if you remove an item A that is required by an item B, both A and B will be removed, since presumably B will be broken without A. An example: let's say you have a Photoshop plugin. It requires that Photoshop be installed in order to operate, so it specifies Photoshop in its requires attribute. Later you remove Photoshop, managedsoftwareupdate sees that there is a plugin installed that requires Photoshop, so it removes the plugin as well.
No checking is done for circular dependencies - so don't make any.
<key>requires</key>
<array>
<string>XcodeTools</string>
</array>If the above dependencies key was included in the pkginfo for ServerAdminTools, it would ensure that XcodeTools was installed before installing ServerAdminTools. On removal, if you tried to remove XcodeTools, ServerAdminTools would also be removed.
This is also a list of other pkginfo items. When processing managed_installs, munki looks at each item in turn. When considering item 'A', if it is installed, or scheduled to be installed, munki looks through the available catalogs, looking for other items that declare that they are updates for 'A'. If it finds any, and they are not currently installed, it adds them to the install list.
As with requires above, this provides a mechanism for munki to automatically discover new updates for items without the admin having to edit existing manifest files. Items that declare (via update_for) they are updates for other items generally are not added to a manifest; Munki finds and applies them "automatically".
Some examples:
<key>name</key>
<string>PhotoshopCameraRaw</string>
<key>version</key>
<string>5.5.0.0.0</string>
<key>update_for</key>
<array>
<string>PhotoshopCS4</string>
<string>AdobeCS4DesignStandard</string>
</array>and
<key>name</key>
<string>iWork09_Update</string>
<key>version</key>
<string>4.0.3.0.0</string>
<key>requires</key>
<array>
<string>iWork09_Update-4.0.2.0.0</string>
</array>
<key>update_for</key>
<array>
<string>iWork09</string>
</array>Note that you would not use this for new versions of a package - these would simply have the same name as the older package, but a higher version number. But some (much?) commercial software packages its updates as updaters or "patches", in which the new package is added to the existing package, instead of replacing it. The update_for key identifies these and provides the "parent" packages they update.
Note also this construction:
<string>iWork09_Update-4.0.2.0.0</string>This tells munki to look for a specific version (in this case '4.0.2.0.0') of 'iWork09_Update'. Without the version extension, munki always uses the most recent (or "highest") version it can find in the catalogs that are available. You can use this construction anywhere you'd refer to a package, including in the managed_installs key of a manifest.
When processing removals, if item 'A' is scheduled to be removed, any item that declares it is an update for 'A' is also scheduled for removal if it is installed.
<key>installed_size</key>
<integer>198356</integer>
<key>installer_item_size</key>
<integer>588922</integer>updatecheck uses these to determine if there is enough free space to download the installer item and install it.
You can specify which architectures a pkg is compatible with:
PowerPC only:
<key>supported_architectures</key>
<array>
<string>Power Macintosh</string>
</array>Intel Only (Both 32bit and 64bit) :
<key>supported_architectures</key>
<array>
<string>i386</string>
<string>x86_64</string>
</array>Apple Silicon (requires either Munki 5.2.1 or later or a Universal2 Python framework with Munki pre-5.2.1):
<key>supported_architectures</key>
<array>
<string>arm64</string>
</array>You may specify which type of Restart you would prefer for a given package:
Shutdown
<key>RestartAction</key>
<string>RequireShutdown</string>Restart
<key>RestartAction</key>
<string>RequireRestart</string>Logout
<key>RestartAction</key>
<string>RequireLogout</string>You may embed uninstall scripts directly into the pkginfo item:
<key>uninstall_method</key>
<string>uninstall_script</string>
<key>uninstall_script</key>
<string>#!/bin/sh
rm -rf "/Applications/Adobe Reader.app"
rm -rf "/Library/Internet Plug-ins/AdobePDFViewer.plugin"
rm -f "/Library/Application Support/Adobe/HelpCfg/en_US/Reader_10.0.helpcfg"
pkgutil --forget com.adobe.acrobat.reader.10.reader.app.pkg.en_US
pkgutil --forget com.adobe.acrobat.reader.10.reader.browser.pkg.en_US
pkgutil --forget com.adobe.acrobat.reader.10.reader.appsupport.pkg.en_US
</string>
<key>uninstallable</key>
<true/>pkginfo items can optionally contain a preinstall_script and/or a postinstall_script. These are embedded shell scripts that are similar to the optional embedded uninstall_script.
These are executed as root. Assume nothing about the environment, including command paths.
Failure of the preinstall_script will abort the installation attempt. Failure of the postinstall_script will log errors, but the install will be considered complete.
pkginfo items can optionally contain a preuninstall_script and/or a postuninstall_script. These are embedded shell scripts that are similar to the optional embedded uninstall_script.
These are executed as root. Assume nothing about the environment, including command paths.
Failure of the preuninstall_script will abort the removal attempt. Failure of the postuninstall_script will log errors, but the removal will be considered complete.
pkginfo files can optionally contain preinstall_alert, preupgrade_alert and preuninstall_alert keys. This allows an admin to prompt the user with a message from which the user can confirm or cancel after they click Install or Remove on an optional install. Confirming will continue the install/uninstall action, cancelling will cancel the install/uninstall action. The default action on the alert is Cancel
These are intended for use with only Optional Installs -- if a user clicks Install on an optional item, if a preinstall_alert is present it will be displayed. If an older version is already installed, and there is a preupgrade_alert present, it will be displayed. If they attempt to remove the optional item and a preuninstall_alert is present, it will be displayed. (A preinstall_alert or preupgrade_alert will not work for a managed install.)
Uses for this would be where a software package has extra detail a user needs to be aware of before installing, updating, or removing, e.g.
- performing an OS upgrade or package install that may take some time
- software that has a brief condition of use (provided, but unsupported).
- install or uninstall of software that may have repercussions (uninstalling this package means you will no longer be able to access foo)
The format for the keys is the same for all three and contains a dictionary of items, all of which are optional
<key>preinstall_alert</key>
<dict>
<key>alert_title</key>
<string></string>
<key>alert_detail</key>
<string></string>
<key>ok_label</key>
<string></string>
<key>cancel_label</key>
<string></string>
</dict> <key>preupgrade_alert</key>
<dict>
<key>alert_title</key>
<string></string>
<key>alert_detail</key>
<string></string>
<key>ok_label</key>
<string></string>
<key>cancel_label</key>
<string></string>
</dict><key>preuninstall_alert</key>
<dict>
<key>alert_title</key>
<string></string>
<key>alert_detail</key>
<string></string>
<key>ok_label</key>
<string></string>
<key>cancel_label</key>
<string></string>
</dict>| Key | Type | Notes | Default Value |
|---|---|---|---|
| alert_title | string | the main alert message text | Attention |
| alert_detail | string | informative text to explain the alert further | Some conditions apply to this software. Please contact your administrator for more details |
| ok_label | string | label text of the confirmation button | OK |
| cancel_label | string | label text of the cancel button | Cancel |
All keys are optional and will use the default text if not specified. This is explicit so if you include a key but leave it blank, it will replace the default value with blank text. For example, if you only wanted to specify alert_detail you would only specify the alert_detail key and string pair in the dictionary item like so:
<key>preinstall_alert</key>
<dict>
<key>alert_detail</key>
<string>Some important information regarding this package</string>
</dict>Using an additional key in the pkginfo file, admins can designate installs/updates or uninstalls that Munki should attempt to install silently in the background before the user is notified of any remaining installs/updates/removals. This feature should be used with care. Installs may occur while the user is running the application being updated or removed. (Use blocking_applications to make this less likely.) Unattended installs/uninstalls are attempted in the background during automatic background runs. If Munki cannot install/remove an item in an unattended manner (because a blocking_application is running), it will try during future runs, and will also display the update in Managed Software Update if the update is still available at the time Managed Software Update is invoked.
unattended_install takes effect for managed_installs and managed_updates Manifests install types, and unattended_uninstalls for managed_uninstalls.
Below is an example of the unattended pkginfo keys, where the install would not be unattended (the user will be notified as normal), and the uninstall is unattended (package will be uninstalled in the background).
<key>unattended_install</key>
<false/>
<key>unattended_uninstall</key>
<true/>Note: this is an optional key, setting it to false is the same as omitting the key altogether.
You cannot use unattended_install or unattended_uninstall with items that require a logout or restart for what I hope are obvious reasons.
Using an additional key in the pkginfo file, admins can designate installs/updates to forcefully logout and/or restart a machine in order to install a package requiring such. Given that this feature has the potential to forcefully restart a machine while a user is performing work or has unsaved work open, it should be used wisely and and admins should provide sufficient notice to their users. We recommend setting force datetimes at least 2 weeks in the future.
The pkginfo key, force_install_after_date, is a date value expressed in the following format: yyyy-mm-ddThh:mm:ssZ. For example, August 3rd 2017 at 1PM would be set like this:
<key>force_install_after_date</key>
<date>2017-08-03T13:00:00Z</date>The date specified here is evaluated in local time, so all timezone specific information is stripped and ignored. In the example above, clients will forcefully logout and perform the install at 1PM based on whatever the local time of the client machine is.
If you need an install/update requiring a logout/reboot to be forced as soon as possible, specify a date in the past. Do note that this may be highly disruptive to your users, though.
When there are one or more items with force_install_after_date set in the list of pending updates, Managed Software Center will display additional informational text and alerts.
If the "deadline" for a forced install is more than a day away, MSC update notifications still only display based on the ManagedInstalls DaysBetweenNotifications setting, which defaults to once per day.
Starting at 240 minutes (4 hours) before the force datetime, the MSC GUI will be displayed with a more intrusive warning notification. This notification will be displayed at 240, 180, 120, 90, 60, 45, 30, 15, 10, and 5 minutes. A final notification will also be displayed roughly 1 minute before force logout/restart.
If a machine is powered off or asleep while a force install is due to take place, it will start at 60 minutes worth of notifications. If the machine then is put asleep until that new 60-minute counter has been started, the machine will perform the force install within minutes of waking up.
For machines that do not have enough disk space to download the item which has a force install date attached to it, Munki will treat those the same way it treats powered off or asleep machines. Once enough disk space has been freed up for Munki to download the force-install item, Munki will set the new 60-minute counter.
There may be cases in which you want to force-install an item that is ordinarily an unattended install but has blocking applications (so as not to update an application if it is running, for example). Even though the item may be marked as an unattended install, because it is a forced install, after the deadline, Munki will forcibly log the user out in order to ensure none of the blocking applications are running when Munki installs the item.
Users who do not want to be forcibly logged out for an otherwise unattended install can use Managed Software Center to install the pending item, and after that installation, Managed Software Center will cancel the forced logout. If the user updates or installs the pending item outside of Managed Software Center, there is no guarantee that the scheduled forced logout will get canceled.
The Munki preference SuppressUserNotification has no effect on notifications for forced installs.
This key allows the admin to specify arbitrary environment variables for use by /usr/sbin/installer.
Some (broken) packages and pre/post script that only do the right thing if /usr/bin/installer's environment is that of the current console user. Since Munki runs as root, this is not the case when Munki installs items.
You may be able to work around broken pre/postinstall scripts that reference the current username or user home by specifying the correct values in an installer_environment dictionary.
Here's the most common implementation:
<key>installer_environment</key>
<dict>
<key>USER</key>
<string>CURRENT_CONSOLE_USER</string>
</dict>Which causes Munki to substitute the current console user name (or root if there is none). Alternately, you could specify a known-to-exist local user:
<key>installer_environment</key>
<dict>
<key>USER</key>
<string>localstudentuser</string>
</dict>This key takes a string in the NSPredicate format, and is an expression that must evaluate true for the package to be considered "installable" on the host. It can be used to support more sophisticated OS X version requirements than can be provided by the minimum/maximum_os_version keys, but can take advantage of any built-in conditions provided by Munki (machine_type, machine_model, etc.) or admin-provided conditions.
A couple scenarios where this may be useful:
- you want to specify specific hardware/software requirements for a package to prevent it being installed on systems that are incompatible
- you have a support package that has at least two versions for different configurations (for example, one for desktops and one for laptops), and you want to be able to give them the same name to simplify your manifests
This is only a filtering mechanism; Munki does not use this expression to determine whether an item is installed or should be installed. If an installable_condition evaluates as false, a warning will be logged on the client in similar fashion to a minimum_os_version that's not satisfied.
For more examples on conditional items in the context of manifests, see Conditional Items.
Here's an example that specifies that a package requires a minimum OS X version of 10.7.5 or 10.8.2:
<key>installable_condition</key>
<string>(os_vers BEGINSWITH "10.7" AND os_vers_patch >= 5) OR (os_vers BEGINSWITH "10.8" AND os_vers_patch >= 2)</string>...or a more succinct version that would evaluate true as long as the version is between 10.7.5-10.7.9 or 10.8.2-10.8.9 inclusively:
<key>installable_condition</key>
<string>os_vers MATCHES '10\.(7\.[5-9]|8\.[2-9])'</string>This key was added in the 3.5 release. Normally, Munki will keep in its cache only the installers for items it has to install (managed installs, managed updates, or updates to user-selected optional installs).
The precache key adds support for downloading to and keeping in the cache optional installs items that have not yet been installed or optional install OnDemand items.
You might want to use the precache key if you have a particularly large installer for an optional install you want people to be install right away (without having to wait for it to download after selection). For example, if you don't want to force your client machines to upgrade to the latest macOS version, but you want the upgrade to start almost right away if the user decides to do the upgrade.
Just keep in mind that disk space may become an issue if you have too many large precache items.
This key was added in the 3.2 release. It adds support for localizing pkgsinfo files so the locale settings of the client machine will show the appropriate strings. The type is a dict of dicts. See the example below:
<key>localized_strings</key>
<dict>
<key>nl</key>
<dict>
<key>category</key>
<string>Wetenschappelijke Software</string>
<key>description</key>
<string>Nederlandse beschrijving</string>
<key>display_name</key>
<string>Nederlandse naam</string>
<key>preinstall_alert</key>
<dict>
<key>alert_detail</key>
<string>Er kan wat gebeuren</string>
<key>alert_title</key>
<string>Let op</string>
<key>cancel_label</key>
<string>Stop</string>
<key>ok_label</key>
<string>Ga door</string>
</dict>
</dict>
</dict>The key(s) of the outer dict should match the desired locale, for instance nl matches the Dutch locale.
The inner dict should contain one or more of the following pkgsinfo keys: category, description and display_name. The values should contain the localized strings.
There's also support for these dictionaries: preinstall_alert, preuninstall_alert, preupgrade_alert.
To get a list of language codes, you can use the following AppleScript snippet:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
property NSLocale : a reference to current application's NSLocale
NSLocale's ISOLanguageCodes() as listor this one-liner:
/usr/local/munki/munki-python -c "from Foundation import NSLocale ; print(NSLocale.ISOLanguageCodes())"To indicate the default language that the strings in the pkgsinfo are in, you should add the fallback_locale key to the localized_strings dict.
<key>localized_strings</key>
<dict>
<key>fallback_locale</key>
<string>en</string>
</dict>- Getting Started
- Overview
- Discussion Group
- Demonstration Setup
- Glossary
- Frequently Asked Questions
- Contributing to Munki
- Release Notes
- Introduction
- Managed Software Center in Munki 5.2
- Manual Apple Updates
- force_install_after_date for Apple Updates
- Additional update encouragement
- Aggressive update notifications
- AggressiveUpdateNotificationDays preference
- Additional Munki 5 changes
- Configuration profile notes
- Major macOS upgrade notes
- Upgrading to Munki 5
- Introduction
- Munki Links
- Product Icons
- Screenshots In Product Descriptions
- Client Customization
- Custom Help Content
- Featured Items
- Update Notifications:
- Introduction
- iconimporter
- makepkginfo
- munkiimport
- managedsoftwareupdate
- makecatalogs
- manifestutil
- repoclean
- Preferences
- Default Repo Detection
- Default Manifest Resolution
- Managed Preferences Support In Munki
- Apple Software Updates With Munki
- Pkginfo Files
- Supported Pkginfo Keys
- Pre And Postinstall Scripts
- Munki And AutoRemove
- Blocking Applications
- ChoiceChangesXML
- CopyFromDMG
- nopkg items
- How Munki Decides What Needs To Be Installed
- Default Installs
- Removal of Unused Software
- Upgrading macOS:
- Apple Updates:
- Securing the Munki repo
- Preflight And Postflight Scripts
- Report Broken Client
- MSC Logging
- Munki With Git
- Bootstrapping With Munki
- License Seat Tracking
- LaunchD Jobs and Changing When Munki Runs
- Web Request Middleware
- Repo Plugins
- Downgrading Software
- Downgrading Munki tools
- Authorized Restarts
- Allowing Untrusted Packages
- About Munki's Embedded Python
- Customizing Python for Munki
- Configuration Profile Emulation
- PPPC Privacy permissions
- AutoPkg
- Repackaging
- Creating Disk Images
- Stupid Munki Tricks
- Troubleshooting
- Professional Support
- Known Issues and Workarounds
- Building Munki packages
- Munki packages and restarts
- Signing Munki
- Removing Munki
- More Links And Tools
- Munki Configuration Script
- Who's Using Munki
- Munki 3 Information
- Munki 4 Information
- macOS Monterey Info
- Pkginfo For Apple Software Updates
- Managing Configuration Profiles
- Microsoft Office
- Adobe Products
- Upgrading macOS: