When setting up my first Munki installation I was confused on the server side of things. It was actually so easy I had a little trouble believing I was done, surely there was more to it! Turns out, no… not really.
What Special Software Goes on the Server for Munki?
Turns out, none. The server side of a basic Munki install is really just a web-server with a specific folder structure. This can be any web server be it IIS, Apache, whatever. So to get Munki running all you need to do is put a folder structure on a web server, install munki-client on the machines you want to manage, then point those machines to the server hosting the munki files. There are great demo setup instructions on the Munki wiki if you are interested in checking them out.
Now I do need to say that if you want reporting (and I’m will to guess that you do) you will need to setup MunkiWebAdmin, MunkiServer, or MunkiReport-PHP. But these are extra server components and are not required to get munki running. We will cover these some other time. All you need to have now to have a functioning Munki server is a web server with the following folder structure:
That is it. Each folder has a meaning and will hold more folders and/or xml files that you create when you add software and scripts to your Munki setup. This process will be covered in another post, but it is worth noting now.
Even though you are done at this point setting up a basic Munki server, it is helpful to understand what each of these folders does. Each Munki folder will hold specific types of data. Here is how I understand the Munki structure.
Catalogs are the lists of software available. You can set up a few catalogs to help develop, test, or deploy software. For example, I have a testing catalog that all new software goes into including software updates. I’m in that catalog and will get new software deployed to me so I can test that the update or installation works and that the software doesn’t break anything… I’m looking at you Java. Anyways, each Catalog you create will be stored as an xml file in this folder.
Manifests are the lists of software that should be installed onto each machine. They are xml files housed in the manifests folder. Normally, each computer will have its own manifest and will check that manifest to see if there is any software that it needs to install or uninstall. You can link manifests to other manifests by including manifests within other manifests. I, for example, have a manifest for each of my machines then have manifests for some labs or job positions (like first floor lab, or technician). Then, if we hire another technician, to get all the software needed for that position onto their new machine I just add the “technician” manifest to the new machines manifest. No more tasks needed to ensure they get all the software they required to do their job.
pkgs stands for packages and is where the software packages and dmgs are stored. So, if you use Munki to manage Firefox, the Firefox dmg will be stored in pkgs. I further subdivide my packages into more folders, like “apps/firefox/” and “scripts/wirelessonoff/”, but this isn’t required. It just helps to keep the pkgs files clean and organized. This really helps once you have a couple of versions of a software package to keep track of. You just go to the folder “apps/firefox/” and there are all the firefox installers, new and old, for you to manage.
pkgsinfo are xml files that contain meta data about the pkgs. For example, in a pkgsinfo file for firefox would be information about what files the Firefox installer puts onto your computer, what scripts to run before or after the install (if any), what OS’s Munki is allowed to install this software onto, and so on.
So What Next?
Now that you have the web server and it has the folder structure you need, you will use your munki-tools to create and add all these xml, dmg, etc. files that we have been talking about to the server. Munkiimport and MunkiAdmin are the tools I use most to do this.