(Want help? I do this stuff for hire.)
The Munki repo structure is something like this:
In this case we used a Mac running OS X 10.10 (“Yosemite”) with Server.app and XCode tools installed, but any webserver with python/git will do.
SERVER SETUP:
1. Mac Server.app -> Web service -> removed default site's redirect to SSL because it uses an untrusted self-signed cert etc. Also enabled directory listing option. So, http://server.domain.org loads properly.
2. Installed latest munki + rebooted server when prompted.
3. Ran munkiimport --configure, answered prompts:
So, fileshare URL is file:///Library/Server/Web/Data/Sites/Default and default editor is vim and default catalog is main. For the other questions we just hit the return key to accept defaults.
4. Downloaded latest Firefox and imported it to the repo, answered prompts accordingly:
Some of these were pre-filled based on the contents of the downloaded .dmg — e.g., it can peek inside and see the app’s name and version. I entered the display name, description, category, developer, and specifed that it can be installed or uninstalled without interaction from the user. At the end, it prompted to rebuild catalogs, and I answered yes. This step scrapes all the individual apps’ pkginfo files into the “main” catalog (if the pkginfo file specifies that it should belong to the “main” catalog), so that the main catalog is totally up-to-date.
5. Ran manifestutil to build initial "staff" manifest, added "main" catalog to it, and added Firefox to that manifest:
Note that by default it got added to the “managed_installs” section of the manifest. That means that if the app is missing, it will be installed, and if it’s installed but outdated, it will be updated. There are other ways to do things (managed_updates = only update it if it’s already there, optional_installs = allow the user to choose to install the app in a “self-service” way) — more on those later.
In this example, we decided on 5 manifests:
students
faculty
sped
admins
tech
We then created a "CORE" manifest, which will be included by the other manifests and will contain the universal things that ALL Macs should have. Saves manifest editing later!
We also decided that we WOULD enable Apple software updates on each client. Note that this means non-admin users CAN upgrade to the latest macOS version, not JUST do routine software updates (patches), because a couple of years ago, Apple in their infinite wisdom decided to roll upgrades out like regular updates.
Anyway, MunkiManifestPicker.command reflects these choices (more on that below.)
---------------------------------------------------------------
CLIENT SETUP:
1. Install Munkitools on client + reboot
2. Run MunkiManifestPicker.command (as admin-enabled user) Source code is here. Paste it into a text file, edit it to suit your needs, and name it MunkiManifestPicker.command, and it will become a double-clickable script.
What it does is, sets the repo url + clientidentifier (a.k.a. manifest) via these commands:
defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://server.domain.org"
This tells it where our repository is.
defaults write /Library/Preferences/ManagedInstalls ClientIdentifier “one_of_the_five_manifests”
Depending on your choice, this sets the manifest.
defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates -bool True
Enables Apple Software Updates.
defaults write /Library/Preferences/ManagedInstalls SuppressStopButtonOnInstall -bool True
Doesn't let the user stop an installation once it begins.
There are other options, see https://github.com/munki/munki/wiki/Preferences for reference.
Alternatively, you can set these options with a custom configuration profile through your MDM:
3. Launch /Applications/Managed Software Center.app and wait for it to find available updates.
---------------------------------------------------------------
CLIENT TROUBLESHOOTING:
If it’s not acting like you expect, run it from the command line with a “v” for verbose:
sudo /usr/local/munki/managedsoftwareupdate -v
The output will tell you what it’s doing and why. Common (for me, anyway) mistakes are:
1. Forgetting to re-run makecatalogs after I add or change something in the repo
2. Fouling up permissions on the pkg itself (hasn’t happened in ages, but used to happen in the early days for reasons passing understanding)
3. STILL forgetting to re-run makecatalogs after I add or change something in the repo, like jeez dude, how many times do I have to miss that
4. Making a custom package, then updating it, AND remembering to run makecatalogs, but forgetting to increment the actual package version (causes MSC to think that the newest version is already installed)
---------------------------------------------------------------
AUTOPKG SETUP:
1. Installed latest autopkg on same server as Munki repo
2. Told it about the munki repo path:
defaults write com.github.autopkg MUNKI_REPO /Library/Server/Web/Data/Sites/Default
3. Looked for a Chrome recipe:
autopkg search Chrome
(Results showed that "GoogleChrome.munki.recipe" was available from the main "recipes" github repo.)
4. Told autopkg to go out and grab all the recipes from the main "recipes" github repo:
autopkg repo-add recipes
5. Made our local copy of the master Chrome recipe:
autopkg make-override GoogleChrome.munki.recipe
6. Edited the override file, changed catalog to "main" AND disabled CODE SIGNATURE VERIFICATION like so (red text):
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version="1.0”>
<dict>
<key>Identifier</key>
<string>local.munki.GoogleChrome</string>
<key>Input</key>
<dict>
<key>DISABLE_CODE_SIGNATURE_VERIFICATION</key>
<string>True</string>
<key>DOWNLOAD_URL</key> <string>https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg</string>
<key>MUNKI_REPO_SUBDIR</key>
<string>apps</string>
<key>NAME</key>
<string>GoogleChrome</string>
(…continued)
7. Actually ran the recipe:
autopkg run GoogleChrome.munki
This downloads the latest Chrome into our Munki repo, and creates a pkginfo file based on how we edited the local override of the master recipe.
8. Ran the makecatalogs command to update the catalog(s) with the latest pkginfo file(s) (THIS IS THE STEP I ALWAYS FORGET TO DO:)
makecatalogs
9. Added "GoogleChrome" (must match "name" key of pkginfo file precisely) to the optional installs section of the "staff" manifest:
NOW, the next time a client using the "staff" manifest checks in, they'll see Chrome in the optional installs area. (Later, we moved it to the managed_installs section cuz everyone needs it)
---------------------------------------------------------------
DEALING WITH MICROSOFT OFFICE 2016:
We used autopkg recipes for the three apps themselves, then manually munkiimported the school’s specific serializer pkg, which we downloaded from the VLSC site using their account. Added the following to the serializer's pkginfo after the basic munkiimport step:
<key>update_for</key>
<array>
<string>MSWord2016</string>
<string>MSExcel2016</string>
<string>MSPowerPoint2016</string>
</array>
Which means that when any of those apps get installed, the serializer tool will automatically be installed and run afterward. We added the serializer to CORE manifest's "managed updates" section, so it will only come into effect when the Office apps are installed.
We added Word/Excel/PPT to the managed INSTALLS section of faculty manifest, for now at least (can move to optional later if you have Macs that DON'T want it.)
---------------------------------------------------------------
MUNKIADMIN (a GUI for managing the Munki server):
1. Downloaded slightly older v. 1.5.2 because our server is on Yosemite
2. The first launch pops open a window, "select a munki Repository" -- navigated to /Library/Server/Web/Data/Sites/Default
3. Went to its preferences and "On Startup" selected "Open previous repository" so it doesn't ask each time
If you make any changes via MunkiAdmin, remember to click its SAVE button to actually write out the changes!
---------------------------------------------------------------
Automating AutoPKG:
Added this cronjob under the server's admin account:
# update Munki repo erryday at 9pm
0 21 * * * /Users/admin/Library/AutoPkg/CRITICAL-RECIPELIST 2>&1 /dev/null
CRITICAL-RECIPELIST in turn contains:
#!/bin/bash
export PATH=$PATH:/usr/bin/git
/usr/local/bin/autopkg repo-update all
for ITEM in "AdobeFlashPlayer.munki" "Caffeine.munki" "DriveFS.munki" "Firefox.munki" "GoogleChrome.munki" "MSExcel2016.munki" "MSWord2016.munki" "MSPowerPoint2016.munki" "munkitools3.munki" "Silverlight.munki" "Skype.munki" "VLC.munki"
do
/usr/local/bin/autopkg update-trust-info "$ITEM”
/usr/local/bin/autopkg run "$ITEM"
done
/usr/local/munki/makecatalogs
# the end.
Alter the ITEMs to suit your needs. Note that you need to have already created and modified recipe overrides and made sure each package works before you can rely on this. Don’t forget to chmod 755 /Users/admin/Library/AutoPkg/CRITICAL-RECIPELIST to make it executable so cron can run it.
---------------------------------------------------------------
CONFIGURATION PROFILES:
Created a default dock using
http://techion.com.au/blog/2015/4/28/dock-master
Then munkiimported it and added it to a manifest, just like any app.
---------------------------------------------------------------
PRINTERS:
For this, you need a list of all print queues + their exact PPDs. Then follow this:
https://github.com/munki/munki/wiki/Managing-Printers-With-Munki
I might do a separate article on this, we’ll see.
---------------------------------------------------------------
Customization, images, icons, etc.
You can customize the appearance of Managed Software Center, load up a photo of the school, make custom links to your helpdesk, etc. as per this: https://github.com/munki/munki/wiki/Client-Customization
---------------------------------------------------------------
References: