Munki: An Introduction..

Hi all. Recently I have been playing around with and configuring Munki for some of our customers. As part of this I have drawn up a number of internal guides / walkthroughs on configuring and using Munki. I’ve been given permission to dress these up and release them on the general public, aka you!

In this blog I will try to provide a basic introduction into the need that Munki fills, and general usage. In later blogs, I plan to detail how to configure Munki admin and server machines, your Munki clients and securing the Munki solution.

Why do I need Munki?

Munki has been developed by an internal group of Mac Admins to provide a means of silently installing software and settings onto Mac clients. It has been upgraded to provide optional installs and user notification via a Software Update App-like Self Service tool (called Manage Software Update). It can also be used to tie into the Apple Software Update mechanism, allowing non-admin local users to run updates on their own Macs.

From Munki’s own website:

“Munki is a set of tools that, used together with a webserver-based repository of packages and package metadata, can be used by OS X administrators to manage software installs (and in many cases removals) on OS X client machines.

Munki can install software packaged in the Apple package format, and also supports Adobe CS3/CS4/CS5/CS6 Enterprise Deployment “packages”, and drag-and-drop disk images as installer sources.
Additionally, Munki can be configured to install Apple Software Updates, either from Apple’s server, or yours.

Munki is currently in use at organizations all over the world, managing software for thousands of Macs.”

Default Behaviour

At the default (minimum configuration carried out) settings, Munki will automatically check in with the Munki Repository server (or ‘Munki Server’) every 60 minutes plus 1-60 minutes – so anywhere between 1-2 hours. If any updates are found, then these are downloaded in the background.

Once cached locally, the Munki client will check if a user is logged in. If none is logged in, a message will be displayed over the login window, whilst Munki runs its install/s. If any reboots are required, these will be carried out automatically. This ‘install at the login window’ behaviour can be suppressed.

Once cached locally, but a user is logged in, the Munki client will display the Managed Software Update application. This will display all of the updates / installs that will be carried out. This application can also be suppressed. Once the user clicks ok, the installs will run. If any need a restart / logout, the user will be prompted. If not, the user will still be asked if they’d like to logout. This behaviour can be enforced.

Additional Options

Munki can be used to provide Apple Software Updates both in addition to ‘normal’ Munki usage, or on its own. This will allow end users to run Apple OS software updates, without requiring them to be local administrators. Ideally, this would be combined with an internal Apple Software Update server so that the IT administration can still manage the updates available to end users.

In either of the above scenarios, the built in Apple Software Update should be disabled so as not to interfere with what Munki offers. Currently, the only limitation is the lack of ability to update Mac App Store Apps, as these are linked into Apple’s payment systems.

Munki can also be called upon and used by a script, either logout (recommended), login (not recommended as logouts will probably be required) or via the LaunchD system. In this instance, instead of having pop-ups for end users, the ‘managedsoftwareupdate’ tool can be called in a script at regular intervals or as desired.

Finally, the Munki server configuration when adding new installers is all command line based, there are alternatives to make life a little easier including a GUI tool that I’d heavily recommend and will touch on later in the series.

Looking Ahead

With the current plans for this series potentially being quite long, I thought I’d lay out a sort of introduction before jumping in. With this view, I’d like to detail the following points regarding this series.

  • These instructions have been written for our internal teams and for our typical installations. Tweaks may be required to fit your exact setup.
  • The server used in these examples is Mac OS X Server 10.8.4
  • The server uses Mac Server App version 2.2.1.
  • The server has been configured with a boot drive called “ServerHD” and a data drive called “DataHD” for the services data.
  • The clients used in these examples are Mac OS X 10.8.4, although the instructions have been tested on Mac OS X 10.8.2+.
  • Munki is provided free of charge under the Open Source license. Although free, your mileage may vary, so test any solutions heavily before rolling them out as ‘live’.

Additional information can be found on the Munki site.

Summary

There you go, a small introduction into Munki and what it can do. Next time, we will jump into configuring a Munki Server (the Darren method), for your Munki clients to talk to.

Any hints, tips or opinions? Let us know in the comments below and I’ll try to respond to as many as I can.

 

Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *