Dealing with Munki

There seems to be a lot of confusion with people who are just starting out with it. There are manifests and catalogs, and optional installs, and included manifests, etc… The documentation does a pretty good job of explaining it, so let me point you there first. But after you go through that, you may still have some questions about practical usage. Well, the best thing you could do would be to set up munki in a development environment and mess around with it. When I first started trying to use munki, I read a lot about it and I talked to Greg Neagle (the creator), but nothing helped quite as much as setting it up and just trying things. Sure, I broke some stuff at first, but when I was done with that, I was fairly confident in my abilities.

• Catalogs
  Every package or piece of software you import into munki will end up in a Catalog. These are just listings of different types of software. You could just have one giant list, or you could piece them out. Personally I have separate catalogs for things like plugins (think flash, silverlight, etc) and management packages (profile installers, configuration packages, etc). These essentially help you organize your entire package collection in munki.

• Manifests
  Manifests are the bit that tell your clients what software they should install or uninstall. Each manifest has a section to include what Catalogs you are going to pull software from. Once you have defined those, you have some different choices on what to do with those packages. You’ve got managed_installs and managed_uninstalls, which are forced, and then you have optional_installs and optional_uninstalls. These are things the users can decide on for themselves. For an extra layer of depth, you can use the included_manifests section to include the information that is already in another manifest. This is good if you want to have a main manifest with configuration everyone will use, but then you want to narrow things down by department, use case, etc. Using included_manifests means less duplication of effort for you!

• PkgInfo
  Each package you import into munki will have a pkginfo file. This file essentially tells munki how to install/uninstall the package. These get generated automatically when you use munkiimport but there are some more advanced configuration options you can find on the wiki.

And finally…

• Pkgs Finally you have the packages you important into munki. Your clients will be able to pull these from the local server rather than having to download individually from the internet. Some people like to repackage these, but, as Greg Neagle likes to say, ‘repackaging is never easier than not repackaging.’

Obviously there is a lot more to know about Munki, but these are the four basic building blocks you will want to understand when getting started. Hopefully I will have more on this for you later!