This article provides information on the Munki repository structure for the Technology Services Munki Mac Endpoint Management system.
A basic Munki repository consists of the following subdirectories:
Contains the installer files for packages. Each package has a corresponding pkgsinfo file in the pkgsinfo directory.
Contains pkginfo files1 that contain installer metadata and settings. Typically, each pkginfo has one or more associated files in the pkgs directory, though there are exceptions.
Additional information on pkgsinfo files can be found on the Munki Wiki.
Contains manifest files1 that contain the information of what packages a particular computer should get. They are essentially a list of the items to install/uninstall or
verify their installation/removal. Additional information on manifests can be found in our manifests article and on the Munki Wiki.
Contains catalog files1 that group software into "channels", allowing IT Pros to deploy certain software installations and
updates to one group of computers, while denying those same installs and
updates to another group. Two common catalogs are "Testing" and "Production". Catalog files should never be edited directly but instead are set on the pkginfo files and computer manifests. Catalogs are searched in the same order as they are specified in the client manifest - catalog order matters. Additional information on catalogs can be found on the Munki Wiki.
icons Contains the artwork for packages that are displayed to users in the Managed Software Center application. The preferred file format is PNG.
Additional information on product icons can be found on the Munki Wiki.
client_resources Contains HTML and other files that can be used to customize the Managed Software Center application for users, including a customized banner image, sidebar, footer, etc.
Additional information on client customization can be found on the Munki Wiki.
1 Structured XML files that conform to Apple's PLIST document type definition
Multi-Tenant Munki (MTM) uses the repository level prefixes to determine which files should be "copied" to directories further down in the hierarchy. The "copying" process itself is actually done through a series of redirects by the Web server.
firefox) or, for vendors with multiple software products, a vendor directory with sub-directories for each software (e.g.
google/drivefilestream). However, units may instead choose to have one top-level directory containing all of their deployed packages.