Munki: Basics

From AFP548 Wiki
Jump to: navigation, search

Components of Munki[edit]

Server-Side Components[edit]


This is the set of directories that Munki requires to function. These directories need to be created on the document root of your web server. The repository name can be whatever you desire but the subdirectories must be as outlined.



A catalog is a list of software that's available in the repository and contain metadata about the software. These are automatically generated by Munki's client-side tool makecatalogs. Think of this as a generated inventory of software in your Munki repository. The listings are aggregated from pkgsinfo.


Manifests are a set of instructions that the client-side of Munki looks to for what to look for and where to look. The manifest is specified in the clients ManagedInstalls.plist's ClientIndentifier key. These can be very simple with a 1:many lab management configuration or much more complex for workstation management like 1:1 for unique users or 1:x for Developers, Support, Editors, etc. You can scale Munki to suit your needs.

You can find a Manifest Template at the official Munki Docs at


This is populated by what are called installer items. Flat-file installers or applications that reside in Munki's repository. This is where you'll place the installer items you want to manage on your clients. Many Disk Images (.dmg) are ready to go without repackaging. Occasionally a Disk Image will need repackaged. One notable example is Opera which launches an EULA when mounted.


Package metadata that's automatically generated by the client-side tool makepkginfo

Client Components[edit]

Managed Software Update[edit]

This is a GUI tool found at /Applications/Utilities/Managed Software It's intended to allow users to manage their updates (if permitted). This is for users to see available updates, optional software and even Apple Software Updates (configuration depending).

Managed Installs[edit]

There are two components called Managed Installs.


There's a file in XML format that resides in /Library/Preferences/ManagedInstalls.plist. This file is what you'll need to configure your clients. You can either configure at build time or deploy via ARD. This contains the settings that point the client to your desired manifest as the ClientIdentifier.

Managed Installs Directory[edit]

Client directory located at /Library/Managed Installs/ that contains cached and log information. This is where you can find information about successful and unsuccessful installs, errors, warnings, etc. When troubleshooting Munki, this is a good starting place.

Munki Repository Management Tools[edit]

Munki installs its repository management tools to /usr/local/munki/. For the purpose of this guide, I'm only going to touch on the essentials for setting up a basic Munki implementation.


This command, when run against an installer item in /pkgs, will aggregate information from the installer item and generate a pkgsinfo file. A sample usage of this is below and is demonstrated in the next steps of this guide. The output of the command is redirected to a file in /pkgsinfo in XML format. It's not required but you can append a file extension for easier management.

/usr/local/munki/makepkginfo /munki_repo/pkgs/sample_software.dmg > /munki_repo/pkgsinfo/sample_software


This command, when run against the repository, will generate a list of all available software that you will be able to choose form in your manifest. This catalog is generated using the information from /pkgsinfo. So if you add a new installer item to /pkgs, you need to generate a new pkgsinfo file from it and then update your catalog with this command. This is demonstrated in the next steps but a sample usage is below.

/usr/local/munki/makecatalogs /munki_repo

Get Started![edit]

Now that you have an introduction to Munki and an overview of the repository, client components and essential repository management tools, continue on to Munki:_Getting_Started to setup a basic Munki configuration on your workstation or server.