Getting Started with Munki (not monkey)

5 April, 2018 update: This page used to have a tutorial that walked you through setting up a bunch of GUI tools to manage and keep up-to-date a Munki server. I've reconsidered, and I don't think that's the best approach for new Munki administrators to take to learning Munki.

First Steps

Here are a series of links you should read and follow, in this order, to explore Munki on your own:

  1. Demonstration Setup: Walks you through a very basic setup, using a Mac as a Munki server and another Mac (or even the server itself) as a test Munki client. Even though you can do so, I'd highly recommend against setting up a Mac running Server.app to be your Munki server. If you use a Mac, just use regular macOS with the built-in Apache.
  2. Overview: If you're absolutely new to Munki, you should really understand the basic mechanics of it and what catalogs and manifests are. If you read the overview and are still confused, ask for clarification from other Munki administrators (see links in Getting Help).
  3. How Munki Decides What Needs To Be Installed: This is one of the most frequently asked questions from new Munki administrators, so it's very important you understand why you may have a Munki item that's in an endless install loop (and how to fix it).
  4. An opinionated guide to Munki manifests : Some opinions on how you should structure your manifests in Munki.
  5. Another opinionated guide to Munki manifests: Some more (related) opinions on how you should structure your manifests in Munki.

Getting Help

And here are some great places to go for help, if you have Munki-related questions:

  1. MacAdmins Slack #munki channel
  2. Munki-Discuss Google Group
  3. MacEnterprise mailing list

Server Setup

Want to secure your Munki repo and/or move it to Linux? You may find these links handy:

  1. Using https / self-signed certificates and basic authentication with Munki: If you want to stay with macOS and have basic authentication on an internal-only server.
  2. Certbot Apache on macOS: If you're going for basic authentication on a public-facing server, and you want a proper (not self-signed) SSL certificate.
  3. Setup a Munki repo on Ubuntu 14.04 - Part 1: Yes, I know it says 14.04, but the basic instructions still work for 16.04, and they'll probably work for 18.04, too.
  4. Certbot Nginx on Ubuntu 16.04 (xenial): Proper SSL certificate for Ubuntu (again, if your server is public-facing).
  5. Using Munki With SSL Client Certificates: Basic authentication not enough security for you? Set up revokable client certificates instead.

Munki-related Helper Tools

Need other helper tools?

  1. AutoPkg: Allows you to automate downloading and installing new software into your Munki repo. Get to know the command-line tool well first if you choose to also install the (no longer maintained) GUI management for it called AutoPkgr.
  2. MunkiAdmin: A great graphical frontend for managing your Munki repo (after you've already understood how the pieces work together... and, frankly, even with MunkiAdmin, I'd still recommend using munkiimport on the command-line to manually import new items that don't come through AutoPkg). As an alternative, you may want to check out mwa2, which is web-based.
  3. MunkiReport-PHP or sal: If you want to add in a reporting piece to see what your Munki clients are up to.

Create an auto-logoff script for Windows 7

One Use Case

I'm not really sure how useful this is to other folks, but we're in a primarily Mac environment and have a Windows computer joined to Active Directory that's handy to use for people's password changes.

Once people have changed their passwords... no need to be logged in any more, so this just logs people out shortly after they've changed their passwords.

You may, of course, find other uses for this, and you can adapt the script as necessary.

Create the script

Using Windows' Notepad (or another downloaded text editor like Notepad++), create a new document and paste this code in:

:: Don't display commands
@echo off

:: Display message to user
echo You will be logged out at the end of the countdown.
echo.
echo Close this window if you want to stay logged in.
echo.

:: Wait 10 seconds
timeout /t 10

:: Log out
shutdown /l

Save the file as autologout.bat on your desktop or someone else you can easily reference later.

Test the script

Now find the autologout.bat file you saved and double-click it. It should have a countdown and then log you out.

Move the script to the startup folder for every user

If the script worked, go to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

Then, copy or move your autologout.bat file to that new location.

It should now log people out 10 seconds after they log in.

Enable AirDrop on wired connections

AirDrop for wireless only by default

airdroponwireless

By default, Apple enables AirDrop only for wireless and not for wired connections. So if you'd like to enable AirDrop for wired connections, launch up the Terminal.app (which you can find in Applications > Utilities), and then paste in one of the following two commands.

Command for only the logged-in user

defaults write com.apple.NetworkBrowser BrowseAllInterfaces 1

Command for all users

sudo defaults write /Library/Preferences/com.apple.NetworkBrowser BrowseAllInterfaces 1

Refresh AirDrop

You may have some luck relaunching Finder, but I'd recommend rebooting your computer entirely, particularly if you're changing the setting for all users, and not just the logged-in one.

Cloning an image using Thunderbolt and Disk Utility

Why would you do this?

  • It's fast. Over Thunderbolt, cloning a roughly 30 GB (of used space) image takes only a few minutes.
  • Minimal additional cost. Sure, you probably paid money for your Macs, but this method uses only included software... and one US$40 cable.
  • No external media or extra setup. You don't have to network your computer, install additional software, or have an external hard drive. You can go straight from computer to computer with just a Thunderbolt cable.

Requirements

  • Two Macs—one source, one target.
  • Rename the hard drive on the source Mac to something unique (don't call it Macintosh HD, which is the default). Easiest way to do this is to go to Finder > Preferences and then check or tick Hard Disks under Show these items on the desktop. Then, when you see the hard drive icon appear on your desktop, you can rename it.
  • A Thunderbolt cable.
  • The main hard drive partition of the source Mac must be equal to or lesser in size than the target Mac hard drive. For example, if you are imaging from 250 GB to 250 GB, that's okay; if you're imaging from 250 GB to 500 GB, that's also okay; but if you're imaging from 1 TB to 500 GB, that won't work.

Procedure

Note: If you're using El Capitan (10.11) or later, the procedure has changed. More details at Cloning an image using Thunderbolt and Disk Utility (post–El Capitan)

The procedure below is for Yosemite (10.10) and earlier.

  1. lightningboltOn the target Mac, reboot the computer while holding down the T key on the keyboard to boot it into Target Disk mode. If you have done so successfully, you will see what appears to be a white lightning bolt on the screen.
  2. On the source Mac, reboot the computer while holding down the Cmd and R keys on the keyboard to boot into Recovery Mode.
  3. Then, connect the Thunderbolt cable to both Macs.
  4. On the source Mac, select Disk Utility from the available options.
  5. diskutility
    Once Disk Utility launches up, click on the main partition (the one you renamed earlier) of the source Mac. Since Disk Utility can sometimes load up the target Mac visibly higher or lower than the source Mac, it's critical that you have them uniquely named (that's why we renamed the drive earlier). So click on that unique name.
  6. Click Restore. You should see the source as the uniquely-named drive.
  7. Then drag the main partition of the target Mac over to the Destination area.
  8. Click Restore.
  9. That's it! Once it's done, you can boot your target Mac into regular mode, and it should be a clone of your source Mac.

Acer Monitor and Mac Computer

We had a bit of trouble at first getting some Acer K272HUL monitors to work with some Macs on campus, and Google searches came up with threads like this, which offered some helpful tips, but not a full solution.

So if you happen to have an Acer K272HUL (or perhaps a similar model) and some Mac desktops, you may find this post helpful.

Problem: We couldn’t get the Acer monitors to recognize our Mac computers (running Yosemite, though I’m not sure that made a difference) using HDMI cables. Then we tried using a MiniDisplayPort-to-DVI cable, and the Acer monitor recognized the connection but wouldn’t display at full resolution (we could get tiny resolution in the center of the screen or pixelated stretched resolution).

Solution: First, on the monitor, go to the settings and make sure the DP version is set to 1.1 and not 1.2.

Then get a MiniDisplayPort-to-DisplayPort connector.

That’s it. Full resolution.

Update (9 January, 2018): So the above blog post was for Mac Pros connecting to the monitor. If you try to connect a MacBook Air running High Sierra, the HDMI connection will “work” but may flicker. You should still use a Displayport connection.

Deleting Mac Keychains in an Active Directory Environment

Update: The easiest way to do this is actually to install Offset and then put a RemoveLastUserKeychains script into /usr/local/offset/logout-every (make sure it's owned by root:wheel and has 755 permissions).

What's the problem?

If you're in a primarily or exclusively Mac environment, but you're managing logins through Active Directory, password changes on the AD level confuse the local Macs, which will log you in just fine but will not know what to do with your previous login keychain.

One potential solution is to delete the keychains after a mandatory password change... or just at a regular interval. Here are two ways to do that.

Method #0: Use a Launch Agent

Go to Deleting keychains at user logout for the best way to do this.

Method #1: Use a Logout Hook

Why you might not want to use the logout hook

Apple deprecated the login/logout hooks as of Mac OS X 10.4 (Tiger), and—as of this writing—we're up to OS X 10.10 (Yosemite), and the hooks still work. In theory, though, Apple could yank support for the login/logout hooks at any time.

Credit where credit is due...

If you'd like to use a logout hook, this is what you do (credit to How to delete Keychains at logout for being the basis of these instructions).

Instructions

Make a location for your script

Amsys recommends creating one special for your organization (they use /Library/amsys, and we would use /Library/siprep), so create one appropriate for your organization.

In the terminal, you can create that directory using this command:

sudo mkdir -p /Library/nameofyourorg

Make your script

To make the script, you can use the graphical text editor of your choice (e.g., TextWrangler or Sublime Text). If you prefer Mac OS X's built-in TextEdit, just be sure you're saving as plain text and not rich text format. Just remember, once you copy the script to /Library/nameofyourorg, that you need to change ownership of the file to root (owner) and wheel (group).

A simple way to use the terminal to make the script (and avoid having to change ownership of the file later) is to just use the built-in text editor, nano:

sudo nano /Library/nameofyourorg/CleanKeychain.sh

Then, paste in this code:

#!/bin/sh
rm -Rf /Users/$1/Library/Keychains/*
exit 0

Then save (Control-X).

Amsys had $USER instead of $1, but I couldn't get the script to work unless I used $1.

Make the script executable

Whether you used a graphical text editor or a terminal based one, you'll still want to change the permissions on the file so anyone can execute it:

sudo chmod 755 /Library/nameofyourorg/CleanKeychain.sh

Add your script to the logout hook

To get the logout to invoke your script, use this command

sudo defaults write com.apple.loginwindow LogoutHook /Library/nameofyourorg/CleanKeychain.sh

Method #2: Use a Launch Daemon at boot time

Introduction

This second method uses a Launch Daemon (which is not deprecated), but it also assumes you will reboot the machine from time to time (for example, if you have your machines scheduled to reboot every night or every weekend).

The advantage, of course, is that if Apple decides to no longer support the logout hook, this method will likely still work. The disadvantage is that this will work only when you reboot the machine and not every time a user logs out.

I haven't found a way to successfully create a launchd process that executes at logout (instead of just login). someone on Stack Exchange claims to have been able to do it, but I couldn't replicate those steps with success.

So what this does is, at boot time at a system level, just delete all user keychains.

Instructions

Create the shell script

Similarly to the other method, we're going to create (if it doesn't already exist yet), a custom directory for your organization:

sudo mkdir -p /Library/nameofyourorg

Then make the script (again, you can do this in your favorite graphical text editor, move it over to the directory, and then change ownership to root user and wheel group, but this is a fairly straightforward way to do it one fell swoop without having to change ownership later):

sudo nano /Library/nameofyourorg/CleanKeychains.sh

In the text editor, paste in:

#!/bin/sh

# Delete keychains for all users
rm -rf /Users/*/Library/Keychains/*

exit 0

Then save (Control-X).

Make it executable

sudo chmod +x /Library/nameofyourorg/CleanKeychains.sh

Create the Launch Daemon

You're going to create a custom .plist file

sudo nano /Library/LaunchDaemons/local.clean.keychain.plist

In the text editor, put in:

<plist version="1.0">
<dict>
<key>Label</key>
<string>local.clean.keychain.plist</string>
<key>ProgramArguments</key>
<array>
<string>/Library/nameofyourorg/CleanKeychains.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

Save the file (Control-X) and reboot.