Connecting a Munki client to the Munki repo

Now that you’ve set up a web server, put the Munki repo folders on it, installed Munki tools on it, imported an item into it, and set up a manifest for it, you can finally connect a Mac client to it.

Good news! Since you installed all the Munki tools (not just the admin ones), your Mac web server that’s hosting the Munki repo can also be a Munki client of itself.

Probably the easiest way to connect the Munki client to the Munki server is to give your Munki repo a fully qualified domain name of munki.YOURSCHOOL.edu/munki_repo

There are certain repo URLs Munki will try automatically. So it’s one less thing for you to define. If you don’t want to give your repo that kind of fqdn or prefer to reference it by IP address (make the IP address is static, then!), you’ll have to set a Munki preference for SoftwareRepoURL:

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://192.168.1.200/munki_repo"
or
sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://somesubdomainthatsnotmunki.YOURSCHOOL.edu/munki_repo"

Reminder: if your Munki repo can be referenced via munki.YOURSCHOOL.edu/munki_repo, you do not need to set a SoftwareRepoURL.

Also, for now we’re just using regular http instead of https, but after you get a little more comfortable with Munki, you definitely want to switch over to https either via self-signed certificate or a proper certificate authority–issued certificate (Let’s Encrypt ones are free).

Now that it’s configured, let’s test it out.

sudo managedsoftwareupdate -v

You should see something like this:

Starting... Checking for available updates... No client id specified. Requesting NAMEOFCOMPUTER.lan... Getting manifest NAMEOFCOMPUTER.lan... Retrieving list of software for this machine... Bytes received: 233 Request failed. Trying NAMEOFCOMPUTER... Getting manifest NAMEOFCOMPUTER... Retrieving list of software for this machine... Bytes received: 229 Request failed. Trying SERIALNUMBEROFCOMPUTER... Getting manifest SERIALNUMBEROFCOMPUTER... Retrieving list of software for this machine... Bytes received: 231 Request failed. Trying site_default... Getting manifest site_default... Using manifest: site_default Preventing idle sleep **Checking for installs** Getting catalog testing... **Checking for removals** **Checking for managed updates** Getting client resources... Bytes received: 242 Getting client resources... Bytes received: 242 No change in InstallInfo. Allowing idle sleep Finishing... Done.

Just as Munki will try to guess the Munki repo (unless you specify it with SoftwareRepoURL), Munki will also try to guess what manifest you’re using (unless you specify one with ClientIdentifier). For greater flexibility, I would highly recommend against using a ClientIdentifier, unless you have a very good reason to do so. Until you can figure out how you want to structure your manifests, it’s best to start with just the site_default manifest you created earlier. That is the last manifest guess Munki makes. So if you later want to target machines more specifically, you can create a serial number manifest or a hostname manifest, which Munki will guess (and use) before even getting to site_default.

Want to see what this would really look like to an end user (who probably won’t be running managedsoftwareupdate manually)?

Go ahead and launch up /Applications/Managed Software Center.app.

Leave a comment Cancel reply