Munki Mistakes Made Right, a Mac AD UK Conference Presentation

Munki Mistakes Made Right, Tom Bridge, Technolutionary LLC
Munki Mistakes Made Right

Thanks very much to the folks at Amsys for having me out to London to present my talk this year at MacADUK, called Munki Mistakes Made Right. Over the last few years, I’ve done probably 25 munki installations, in groups as small as a few clients, or as many as a hundred. There are always challenges in implementing Munki well, especially as the product matures and grows and the ecosystem around it changes to add tools like autopkg, Jamf Pro, and other solutions that can be co-implemented with Munki.

I’ve learned a lot from my implementations, and I want to share that with everyone, that, as the saying goes, that my mistakes may be avoided for future generations of admins. I’ve prepared a few sections of this presentation on various mistakes I’ve made (security mistakes, configuration mistakes, catastrophic mistakes) and how we addressed them in practice. This talk shouldn’t be seen as totally conclusive of all the mistakes that one can make – folks are always coming up with new and creative ways to break things, as well they should – but it’s a good place for me to talk about the ways we’ve been changing our existing environments to make them better, stronger, and faster.

There are some things that I’ve released recently, code-wise, that get callouts in this presentation, and I want to make sure they’re called out clearly here for ease of use:

Munki in a Box 1.5.1

I released Munki in a Box 1.5.1 last week, and it was largely a maintenance release. The following changes should have been expected: by default, Munki in a Box will now setup HTTP Basic Auth set on a password of your choosing. In addition, it’s designed to be used with an HTTPS-native server, which you should be using anyway. The old security branch, which 1.5.0 was based on was something that walked that line, but it was time to fold that branch back in. So I did. 

In addition, MIAB 1.5.1 now creates local overrides for all the autopkg recipes that are specified in the initial command variable, to better handle the trust package portion of autopkg.

Change Munki, Tell Slack

As part of the talk, I’m going to explain why a configuration manager or Mac-capable MDM is your best friend, but facing a lack of those for budgetary or administrative reasons, I’m going to give you a tool to deploy changes to your fleet in reportable ways.

If you just need to change one setting, there’s Change Munki, Tell Slack.

If you need to change an array of settings, there’s Change Munki, Tell Slack Many Things.

Both will handle a scripted change of your Munki preferences file and pass that information along to a Slack channel of your choosing via a webhook.

Slides & Notes

I’m making my slides and presenters notes available as a PDF for Download, in case you might enjoy it. If you have comments on the scripts above, please let me know, or suggestions for converting them to python, both are welcome.

A group of laptops, set aflame by bad profile,  cost money and time
Why Configuration Management Matters

Munki Mistakes Made Right (PDF)

Munki-in-a-Box Adds HTTP Authentication and SSL

Tonight I’ve released a test branch of Munki-in-a-Box that adds a significant feature: Out of the box HTTP Authentication over SSL for a higher level of security.

Previous versions of Munki-in-a-Box have leveraged transport layer security to make sure that the packages and manifests sent from the server to the client were not captured in transit. TLS is helpful for making sure that you’re talking with the right server, provided that you haven’t accepted a false certificate. This new version seeds the authentication credentials to the client through the ClientInstaller.pkg file created by the script, and then provides HTTP Basic Authentication setup files for your Server.

This does make a pretty stark change: The Software Repo now has to be in the Server’s path, and by default, it will be a folder marked munki_repo in /Library/Server/Web/Data/Sites/Default. Server cannot apply .htaccess and .htpasswd files outside of /Library/Server, so the repository has to live there directly instead of in /Users/Shared.

You can set the password for HTTP Basic Authentication in the initial declaration of variables.

Next up? Figuring out how to automate the setup of a CA for device certificate signing.

Munki-in-a-Box 1.5.0 Beta 1

When Rich Trouton recently blogged about automating the setup of Server.app, we talked a bit about how it might apply to Munki in a Box. The idea of having a version that you could run entirely without having to have pre-loaded Server.app was attractive, as it would save steps.

On the heels of the work earlier this week with getting webappctl tamed for use at the command line, I had all the pieces necessary to complete the project, just a week after commissioning.

To use this script to its fullest, you need a copy of the AppStore Installer Package for Server.app (here’s how to grab it), as well as a good hostname to use for your server. That means the hostname needs to be ready in your DNS for the script to work. I suppose I could write a check for that, and will for beta 2.

But for now, 1.5.0 beta 1.

Accessing Server.app’s Web Application Toggles from the Command Line

Apple’s Server.app offering has a strong command line interface that is usually tied to the serveradmin command verb. This is great when you want to start or stop the web service, as well as view all of the Apache settings:

sudo serveradmin start web
sudo serveradmin stop web
sudo serveradmin settings web

But the thing I really, really wanted to do with serveradmin was turn on the PHP Web Application, because Munkireport-PHP relies on it being running, and if serveradmin can’t engage the PHP application engine, I was going to be unable to control it programmatically, or view its status with a check.

I submitted a bug to Apple that it wasn’t available as part of serveradmin, and I fully expected it to be closed with “functions as intended.”

And it was!

But there was a pleasant note at the bottom below:

You can enable/disable PHP from the command line, just not with serveradmin. The supported way is:

sudo webappctl [start|stop] com.apple.webapp.php

This, of course, got me reading the (ample) manage for webappctl.

webappctl recognizes the start or stop argument to activate or de-activate the webapp specified by webapp-name.  If the webapp-name is specified as "-", the start/stop/status action applies to all webapps represented with a plist present in /etc/apache2/webapps/.  In the case of a restart "-" action, the set of running webapps are stopped, then started. (In the case of a restart for a specific webapp, the webapp will be stopped, then started, even if it was not running before.)  If the status argument is specified, a list of enabled webapps is displayed. The tree[s] argument displays the hierarchy of webapps declared by the requiredWebApps property.  The optional vhost-name argument specifies the name of the virtual host though which the webapp is to be proxied.  If omitted the default wild-card virtual host is used.

This means that you can easily start or stop the PHP and Python web applications programmatically with the following commands:

sudo webappctl start com.apple.webapp.php
sudo webappctl stop com.apple.webapp.php

sudo webappctl start com.apple.webapp.wsgi
sudo webappctl stop com.apple.webapp.wsgi

As well as get their status from the command line:

vm1011:apache2 ladmin$ sudo webappctl status -
web:webAppState:_array_index:0:virtualHostName = "-"
web:webAppState:_array_index:0:vhid = "-"
web:webAppState:_array_index:0:state = "RUNNING"
web:webAppState:_array_index:0:webAppName = "com.apple.webapp.php"
web:webAppState:_array_index:1:virtualHostName = ""
web:webAppState:_array_index:1:vhid = "127.0.0.1:34543_"
web:webAppState:_array_index:1:state = "RUNNING"
web:webAppState:_array_index:1:webAppName = "com.apple.webapp.wsgi"
web:webAppState:_array_index:2:virtualHostName = ""
web:webAppState:_array_index:2:vhid = "127.0.0.1:34580_"
web:webAppState:_array_index:2:state = "RUNNING"
web:webAppState:_array_index:2:webAppName = "com.apple.webapp.wsgi"

OR

vm1011:apache2 ladmin$ sudo webappctl status -
web:webAppState:_array_index:0:virtualHostName = "-"
web:webAppState:_array_index:0:vhid = "-"
web:webAppState:_array_index:0:state = "RUNNING"
web:webAppState:_array_index:0:webAppName = "com.apple.webapp.php"

This opens the door further for a version of Munki in a Box that could configure Server.app if it isn’t already, including the activation of the web service and the PHP web application service. This is good news.

Munki in a Box

One of the projects I’ve been working on for the last year is Munki in a Box, designed to take your bare Mac server to being a fully-implemented and ready-to-roll Munki server with automatic management through AutoPkg and AutoPkgr, GUI configuration through MunkiAdmin, as well as an inventory control scheme using Munkireport-PHP.

You can read up on the project at Github, and I’ll be updating this blog going forward with more details.

Version 1.4.0 is the current release, and it contains everything you need to get up off the ground.

Version 1.5.0 is in development, and will handle configuration of your OS X Server immediately after download of the Server.app binary, all from the command line.