Managing Configuration Profiles - lesula/munki GitHub Wiki

Using Munki to manage configuration profiles

Introduction

Since version 2.2, Munki offers "native" support for configuration profiles. Instead of having to wrap a configuration profile in a package to be able to deploy with Munki, Munki supports configuration profiles as an item it knows how to install and remove without "wrapping".

Details

Use munkiimport /path/to/some.mobileconfig to import a .mobileconfig file into your Munki repo. Like a package, munkiimport will create a pkginfo file, add it to your pkginfo directory, and import the .mobileconfig file into the pkgs directory.

Configuration profiles should use the pkginfo key install_type with value profile to specify that Munki should use the /usr/bin/profiles command to install the profile. Likewise, an uninstall_method of remove_profile specifies that Munki should use profiles to remove the profile as well.

Upon installing a configuration profile, Munki writes a receipt to the client's Managed Installs directory. Note, this is not the same as the OS X installer package receipts database. When removing a profile, Munki will remove this receipt.

The profiles command will replace an existing profile with a new profile if the profiles share an identifier. Therefore, the profile's identifier value is used for determining identity. The UUID is not considered.

From there, you can treat it in manifests as you would any other piece of software -- you can add it to managed_installs, managed_uninstalls, optional_installs, etc.

How Munki Determines if a Profile Should be Installed

When examining whether to install a profile, Munki considers several conditions. If any of these conditions are false, Munki will try to install the profile.

Munki considers the following conditions, in this order:

  1. Is the profile's identifier in the output of profiles -C?

    Every profile has an identifier, with a recommended value of a reverse-domain name uniquely identifying the profile. (e.g. com.myorganization.SoftwareUpdateSettings). Munki will compare the profile it is considering installing with the results of profiles -C to see if there is a match. For this reason, updates to an existing profile must use the same identifier (but a different version) to be considered for installation.

  2. Is there a receipt for this profile identifier?

    Even if a profile has been manually installed, without a profile receipt, Munki will install the profile.

  3. Does the hash of this profile match the receipt's hash_value match?

    The hash value is generated by feeding the .mobileconfig file through a sha256 hashing algorithm. The hash is not based on the identifier, nor the UUID.

  4. Does the ProfileInstallDate from the profile's receipt match the ProfileInstallDate specified by profiles -C?

    In the event that these dates differ, even thought the identifier and hash match, Munki will install the profile.