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.
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.
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.
5. 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.
8. You will be asked to confirm that the installer needs a restart. Click “Continue Installation”. Once the install is complete, click “Restart”.
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"
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"
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
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
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
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
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
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.
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.
23. If there are installers it needs to run, Managed Software Update will download these now and cache them in /Library/Managed Installs/Cache.
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.
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.
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”.
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.
28. If you didn’t follow step 19 above, you will be asked to logout (recommended) or to continue, as per the below.
29. Managed Software Update will now run all of the installers it has cached.
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.
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.