Endpoint Services, Munki, Repository Structure
This article provides information on the Munki repository structure for the Technology Services' Munki Mac Endpoint Management system.
- Munki Mac Endpoint Management
- University of Illinois IT Pros leveraging Technology Services Endpoint Services' Munki Mac Endpoint Management
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 is a hierarchical structure of nested Munki repositories with files "copied" down the hierarchy of directories. This allows for the Endpoint Services (EPS) team to provide centrally-managed packages while allowing different units at the University to have their own departmental repositories.
- The global level contains software available for all users of the Multi-tenant Munki system. The global level only contains free software.
- The UofI level contains software that is licensed to all campuses under the University of Illinois System.
- The campus level (UIUC, UIC, UIS, etc.) contains software that is licensed to specific campuses.
- The unit level (LAW, ED, TECH, etc.) is a department's private repository and contains departmental-licensed software. This is the only level in which MTM users have write-access.
The MTM system uses the 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.
- Files at the global level, with filenames beginning with "global_", are "copied" down to the UofI level (as well as any additional repositories further down the hierarchy).
- Files at the UofI level, with filenames beginning with "UofI_", are "copied" down to the campus level (as well as any additional repositories further down the hierarchy).
- Files at the campus level, with filenames beginning with "UIUC_", are "copied" down to unit level repositories that are nested below it (as well as any additional repositories further down the hierarchy). IT Pros can then utilize any of the upstream files that have been "copied" to their unit level as well as any of their own packages that they add to their unit level repository.
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.