Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Catalogs, Manifests, Packages: Anatomy of Munki
Munki consists of four major object types that you're going to need to be familiar with. Each of them have clear roles and structures, and it's really important to understand how they all fit together and how to build them.
Much like a shipping manifest, Munki's Manifests are a list of items that must be checked off during a run of the Managed Software Center tools. Manifests are structured XML files that conform to the Apple PLIST DTD. They contain a number of key arrays designed to denote specific procedures.
Manifests require Catalogs to properly reference packages. Think of Catalogs like a retail store, and think of Manifests like a shopping list. All the items on a manifest need to be present in the Catalog for a successful run. This would also allow you to have different versions of a software package for a production catalog than for testing catalogs.
This is the shopping list of packages from the repository that Munki will install on a machine that references this manifest.
This is the shopping list of packages from the repository that Munki will uninstall on a machine that references this manifest.
A manifest may include another manifest's name for reference. This would allow you to have multiple manifests for a given machine. For example, you might have a master apps manifest, a creative apps manifest, and a windows vm manifest that installs three separate sets of packages. Your machine's manifest could reference them all for simplicity's sake, and for the sake of only having to update a few manifests, rather than every manifest, when changes and updates are made.
If you have update packages for installed packages on a machine, they can go in the Managed Updates section.
If you have software that Users may install themselves, but aren't required to have, they can go here, and then they are available from within Managed Software Center for optional download and install.
Think of Catalogs like retail stores. The items on their shelves are the items in the store's Catalog. Catalogs are generated by
/usr/local/munki/munkiimport while importing packages, or by invoking
You should not edit the catalogs manually. Let
/usr/local/munki/makecatalogs do it for you.
You may have as many catalogs as you like with Munki, but as many as you have, you have to manage them all. Many shops tend to default to
Packages are what Munki installs. They consist of a pair of logical items in munki: the package itself, and the pkginfo file that determines some of the niceties of install. You have a pair of directories in your repository, one for the .pkg file (called pkgs) and one for the structured XML file that conforms to Apple's PLIST DTD (called pkgsinfo). The Packages are large binary objects - for the purposes of this document, they're black boxes, you don't care about them - and the Package Info files contain everything else you need to know.
Much like the Manifests, the Package Info files contain key arrays that determine how and if the Packages are installed. A full list of supported pkginfo keys is available, but this section will give you some of the highlights.