Munki Configuration Part 5: The client Mac

Welcome to part 5 of the Munki blog series. In this post, I will show you how I install and configure the client Mac / s for Munki.

Some notes for this series as a whole:

  • 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.

Guide

You have your Mac Server installed and configured with 10.8.4 and Server app 2.2.1. This has both forward and reverse lookups configured and working fine. I will also assume that you have already followed all the steps in part 1 and part 2. Part 3 and / or part 4 must also have been completed.

Downloading and Installing the Munki Client Tools

1. The installer for the client Macs is actually the same as for the Admin Mac. Navigate to code.google.com/p/munki and click the “Downloads” link.

Downloading and Installing the Munki Client Tools

2. Select the “munkitools-[version number].dmg” link. In the example this is “munkitools-0.9.0.1803.0.dmg”. On the next screen click the link next to “File” to start the download.

 

download installer package munki

3. Once this has downloaded, quit your web browser and navigate to your default downloads folder. Mount the freshly downloaded disk image.

4. What you will find is that Gate Keeper will prevent a double click to launch the installer. Instead, either disable Gate Keeper for this installation (“System Preferences” > “Security & Privacy” > “Allow applications downloaded from:” > “Anywhere”) or right click, select “Open” and “Open” again.

allow disable gatekeeper munki

open gatekeeper

5. Continue through the installer until you get to the “Customize” option. Select this.

Continue through the installer until you get to the “Customize” option. Select this.

6. By default, all options are enabled. The options are detailed as follows:

a. Munki core tools – The core tools for Munki to work. This is required for the client Macs and the admin Mac / s.
b. Munki admin tools – The admin Mac / s related tools. This is not required for the client Macs but is required for the admin Mac / s.
c. Managed Software Update – This is the GUI tool the client Macs will use to install the updates from Munki. This is only required on the client Macs and not the admin Mac / s unless they will also be clients.
d. Munki launchd agents – These are the tools used to trigger update checks by the client Macs. This is only required on the client Macs and not the admin Mac / s unless they will also be clients. This option will require a restart as part of the installation.

7. Deselect the second from the top option (detailed under B above) and continue the entire installation.

munki managed software installation

8. You will be asked to confirm that the installer needs a restart. Click “Continue Installation”. Once the install is complete, click “Restart”.

munki continue installation

9. Once rebooted, log back into the Mac. You have now completed the installation of the Munki client tools onto your client Mac.

Configuring the Munki client

10. The client-side configuration of Munki is based around a standard, XML-formatted plist file called “ManagedInstalls” and located in “/Library/Preferences/”. Being a standard plist file, I will talk you through setting some of the common options using the ‘defaults write’ command.

If you are using a Monolythic deployment system, you can carry this all out in the master image, then deploy post-configuration. Alternatively, as you are producing a standardised plist file, simply use MCXs or Profile Manager’s Profiles to push the entire plist out where required.

Please Note: There are a number of supported ManagedInstalls.plist keys, most of which are not covered here. For details and information, please visit the Munki wiki page here.

11. As all of these commands are going into a system level preference, we will need to run these as root. As a result each will be prefaced with ‘sudo’. The plist file doesn’t currently exist, but one of the good things with defaults write is that it will create the file if required.

12. This first command points the client to your Munki server and the munki_repo. The format is “http://[server address]/[munki_repo name]” (e.g. “http://munki.amsys.co.uk/munki_repo”). The server address can be IP or DNS but needs to be reachable and resolvable by your client Macs. Type in the following command, edited for your specific site (Note: This IS all on one line, despite how it might appear):

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://munki.amsys.co.uk/munki_repo"

tell the client Mac which manifest it should check

13. The next step will tell the client Mac which manifest it should check on your Munki Server. In my previous blogs we have used “basic_manifest” as our primary manifest. Type in the following command, edited for your specific site and needs:

sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "basic_manifest"

munki managed installs

14. With these two settings changed, the Munki solution should work fine. The next few entries are optional (but ones I have used in the past) with their usage explained.

15. Install Apple Updates – Munki has the ability to offer Apple Software Updates within its “Managed Updates” Application, even to non-administrative users. Potentially combining this with a local and managed SUS you can allow users to keep their own Macs up-to-date. Type in the following command:

sudo defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates True

Install Apple Updates

16. Days Between Notifications – By default, Munki will notify a logged in user once a day, if it detects that there are updates available. You can increase this number by using the below command, replacing “1” with the desired number of days.

Please Note: Do not use this option to suppress user notification. It won’t always work and there is another option for that as detailed below.

sudo defaults write /Library/Preferences/ManagedInstalls DaysBetweenNotifications –int 1

Days Between Notifications

17. Suppress User Notification – By default, if a user is logged into the Mac and Munki detects and update, it will display the Managed Software Update application. If this is not what you want (for example in an education environment), use the below command:

sudo defaults write /Library/Preferences/ManagedInstalls SuppressUserNotifications True

Suppress User Notification

18. Suppress Auto Install – By default, Munki will automatically install updates it finds if at the login window. To disable this behaviour, run the below command:

sudo defaults write /Library/Preferences/ManagedInstalls SuppressAutoInstall True

supress user notifications munki

19. Install Requires Logout – By default, Munki will always recommend a logout unless and installation requires it. If you want (to ensure there are no open apps) to enforce it for all Munki installs, use the following command:

sudo defaults write /Library/Preferences/ManagedInstalls InstallRequiresLogout True

install requires logout munki

20. And that’s your Munki client configured.

Using Managed Software Update

21. As part of the installer we ran during steps 5 to 8, an additional application is installed in your Utilities folder called “Managed software Update”. This application is used by the client Mac to interact with the Munki solution using a GUI tool.
Using Managed Software Update

 

22. Double click the application to launch. It will start to test its connection to the Munki Repo before checking what items it needs to install.
Double click the application to launch

23. If there are installers it needs to run, Managed Software Update will download these now and cache them in /Library/Managed Installs/Cache.

check for available updates

24. If you have enabled the option to check Apple Updates (step 15) this check will now be carried out, otherwise this will be skipped.

check for apple updates

25. Once complete, you will be presented with a summary of the updates available. If the above checks were carried out by Munki’s LaunchD timers, the first popup would be this box. This is what is suppressed by following step 17 above. Click “Later” to postpone the installs or “Update now” to continue the install.

Munkis LaunchD timers

26. Once complete, you’ll be asked where you’d like to save the package information file. MunkiAdmin should auto populate the name and the location. Confirm that the “pkgsinfo” folder is in your working “munki_repo” folder and click “Save”.

munki admin managed software

27. If you followed step 19 above, you will be asked to logout as per the below screenshot. The remaining steps (29 onwards) will happen over the login window.

managed updates logout required

28. If you didn’t follow step 19 above, you will be asked to logout (recommended) or to continue, as per the below.

logout recommended

29. Managed Software Update will now run all of the installers it has cached.

installing java updates

30. Once complete, the Managed Software Update will quit itself. If you re-run the application and there are no further updates, you will get the following message.

your software is up to date

Summary

That’s it; you now have a rough and ready understanding of how to get your clients using Munki and how to use the GUI client application. If you’ve been following the series you should now be able to get a basic Munki solution up and running! I hope you’ve found this series helpful and informative. Keep an eye out (or subscribe to us) for further Munki related blogs, amongst other things that take my fancy.

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.

9 Replies to "Munki Configuration Part 5: The client Mac"

  • Hey guys,

    Just a note to say that the Munki Series will return in 2014……

    Once I’ve checked my instructions on 10.9 and then wrote some new material!

    Thanks for checking them out 🙂

    Darren

  • Hi, great blog! Found it very informative. I have just begun to look into Munki, and I found your blog about Munki very good and easy to follow. Just one comment, I am looking for info about how to be able to use different catalogs/manifests depending on the user logged into to the Mac. Is that possible to do, is this something that you might be covering in future posts?

  • Hi Rignell,

    I’m glad you’ve found it helpful and I’m happy that it’s helped other people get involved with this awesome solution.

    I’m afraid that by default, Munki is not designed to be used as such. Additionally, the catalog isn’t set on the client but in the Manifest.

    You could possibly script a change of manifest but that has the potential to leave a Mac client in an unknown state.

    For example, if client A had a manifest (1) that includes Firefox and Chrome, but the manifest was changed to Manifest 2 that doesn’t have Firefox, how could you continue to push out updates to firefox?

    What is it you actually would like to accomplish?

    Thanks

    Darren

    • Well, for example, I got 3 users working with Adobe software, and I want to distribute for example Photoshop to these 3 users, but only these 3, how can I accomplish that?

      Due to limited licenses I don´t want to make the software available for all my users.

      Now I have been playing around with manifests, but I am not sure that I am thinking in the right way.

      I have set up an image where I have pointed out the munki server and one standard_manifest file.
      But I have not connected any software in that manifest, instead I use nested manifests based on development, testing and production in that order.

      Am I thinking the right way there? I have read that I can use some statements in the manifests but I haven´t got around to try that just yet.
      I am also thinking about active Software Update on my munki server to serve as a software update server locally, have You done that before?

  • Hi Rignell,

    I’m sorry to say that is not something that Munki is designed for and, to be honest, it’s not something I’d recommend in any case. One example is that to deploy and remove Photoshop (for example) it would have to be done fully at each login and logout and could take a long time, reducing the user experience.

    You can certainly nest manifests, for example:

    Manifest A – MS Office with no catalog
    Manifest B – Adobe Photoshop with no catalog
    Manifest C – Firefox with no catalog
    Manifest D (office user) – With no items, but the included manifests of A, B and C and with a ‘live’ catalog.

    Although what I’d recommend is start simple then once you happy and confident, build up the complexity.

    As far as Software Updates, Munki can be used to replace the Software Updates application, by manually loading in the Apple updates, loading in Apple Update metadata, or by enabling it to act as a proxy for updates. This is described in more detail at:
    https://code.google.com/p/munki/wiki/AppleSoftwareUpdatesWithMunki

    Hope that helps

    Darren

  • Hi Darren!

    Thanks for your responses, I will dig in a little deeper having your answers in the back of my head when designing a solution that fits my needs.

    Best regards,
    Rignell

  • Philippe C.

    Great Information, thx alot!

    Take care, you got a typo in:

    “sudo defaults write /Library/Preferences/ManagedInstalls DaysBetweenNotifications –int 1”

    –> Should be DaysBetweenNotification without s

    “sudo defaults write /Library/Preferences/ManagedInstalls DaysBetweenNotification –int 1”

    Best regards,
    Philippe C.

  • Philippe C.

    Hi Daren,

    Darn, I meant the

    SuppressUserNotification

    -> this one (strangly) got no s!

    Correct string above then would be:

    “sudo defaults write /Library/Preferences/ManagedInstalls SuppressUserNotification True”

    Philippe

Leave a Reply

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