We interviewed Chip Pearson of Jamf Software this week on the pod, and the episode dropped today, and if you’ll pardon the cliché, it’s our best episode yet. Chip gives us a view into what it was like to be a Mac Admin in the days when Timbuktu was king, when AppleTalk Zones were still a big potential hurdle, and the Mac IIcx was the workstation du jour. He talks about quitting his job one morning, what it’s like to move from consultant to product to chairman of the board.
I remember very clearly seeing Chip speak at Macworld when I was still a very wet-behind-the-ears IT consultnat, and his message of empathy and focus on the role of the individual in tech’s embrace within your organization was very critical.
This was a fun interview, and it’s worth your time. Thanks Chip!
This photo, from the Davis Enterprise, circa 1986-ish?, shows me with my third grade teacher, my elementary school principal, my Dad, and an engineer from the University in the town I grew up in.
I am absolutely a product of growing up in a University town, with involved parents, with schools that saw the future early and had the connections to figure it all out.
The next generation of people that do what we do now are out there, and they have to be more representative of our world than our current community is.
We all come from somewhere. There’s a spark in everyone’s life that makes a job a career. We can be the principal, the engineer, the parent, the teacher. Who are we preparing for what comes next? That’s what Carole Franti, Mary Ellen Dolcini, Adam Bridge and Charles Soderquist taught me, starting with that Apple ][. That’s why I give talks and teach workshops now.
The existing complexity of DEP, though, gives us choices. There’s no reason we couldn’t setup multiple MDMs for multiple departments within an organization, allowing central management of assets, and separate management of devices at the department levels, allowing for good competition between MDM vendors in the mid-level of the environment. Having multiple options is good, because it gives us choice, and it avoids obvious anti-trust complaints.
Read the whole thing. Complex shouldn’t be immediately pejorative. Good management can, and almost should be considered a complex task.
Hopefully by now you’re aware of Apple’s Device Enrollment Program (DEP), which allows you to specify a Mobile Device Management (MDM) server for your devices to check in with during their initial setup process. This applies not just to iOS devices, which substantially benefit from enrollment in MDMs, but also to Macs, which traditionally have had fewer benefits.
That has substantially changed in the last few months.
A month ago, the Mac Admins Podcast sat down with Erik Gomez of Pinterest to talk about using MDMs to install Mac applications – including root agents like Puppet, Chef and Munki. Erik designed a workflow — and built some tools himself — to configure those root agents and engage them in a seamless series of actions for onboarding new staff. The goal was simple: fully utilize DEP and MDM to install their management agents and software management scheme, as well as customize the device in a way that their engineers normally would ahead of deployment.
The experience of rolling out new equipment to new staff, or returning staff, can be a whole lot less hands on for IT Admins, and that’s an excited part of this.
This process is going to talk about several different important parts, and I want to lay out what you need to make this work.
DEP Account – This should go without saying, but you need a DEP Account. That involves getting a customer number from Apple, and if you’ve got a retail store near you, their business team can help with this. Please stop and read the Deployment Program Help if you have questions. Please note: It can take more than a week to get this done, so start early.
Developer Account – This process requires that you have a signing certificate that is signed by the Apple Worldwide Developer Relations Certificate Authority. There can be no substitutes, so you’ll need to join the Developer Program. It’s $99, and you should probably already have this anyway.
SimpleMDM Account – SimpleMDM is one of the few MDMs that support the InstallApplication verb in the mdmclient binary for the Mac so far(1). You can try it out for 30 days with no credit card. Devices start at $30/year.
A Web Server – You’re going to need a place to host your signed application packages and a JSON file. It’s best if it has an SSL/TLS Certificate installed and configured for use.
InstallApplications Script – You will need the InstallApplications project from Github. This is the glue that makes everything else possible. InstallApplications is the actual signed package you’ll be installing from the MDM, which will in turn reference the JSON file on your web host, and then process the packages specified therein. This is a great way to stage a bunch of useful content on the machine that can then be called in a coherent process to take the machine from fresh-from-Apple to fresh-from-your-organization.
DEPNotify – There are few things as bad as a process with no interface. Users can grow confused or impatient if expectations are not properly set. DEPNotify is a good way to message to your users what is happening with their brand new computer.
During Setup Assistant, a machine that is registered with DEP will check in with Apple’s Activation Servers, and based on the hardware model identifier and the serial number, be assigned to the MDM that corresponds with its record in the DEP portal. At that time, the MDM in charge of the situation can deploy pre-stage packages during the Setup Assistant.
That’s where this process comes in. You can create and sign the InstallApplications package with your Developer certificate, and then deploy that LaunchDaemon to the machine in a safe method without ever touching it. InstallApplications works by referencing a JSON file that is stored on the internet that provides a series of package URLs, file locations and file checksums for the packages you want to install on the machine before and after the Setup Assistant completes.
The nice thing about InstallApplications is you only need to rebuild the package if the location of the JSON file — or some of the attendant details for how it’s secured — have changed. Ideally you build it once, and then handle the rest via the JSON file. Once you have selected your pre-stage and stage 1 and 2 packages (of which there can be a number of each, you’re not limited to one package per stage), make sure to capture the appropriate checksums with the shasum -a 256 /path/to/your/cool/package.pkg and embed the values appropriately.
As part of our install, we’re dropping in the DEPNotify binary and the munkitools package into the pre-stage, since they don’t require a user session, and then a trigger for DEPNotify that performs the first login tasks during Stage 1. We’re doing our Munki configuration via SimpleMDM’s support for custom profiles, so those settings are already present when our trigger script runs after the first user logs in. Our script, a sample of which is linked here, kicks off the DEPNotify application, and begins to guide the user through what will follow.
I also wrote a second script that is installed as the last thing our Munki server doles out for install. It issues one last command to DEPNotify and then cleans up the log file. You can later create an uninstaller for DEPNotify that cleans up the application.
Sign this package with your Developer ID Certificate.
Upload this to SimpleMDM as a macOS Package and Configure it to be installed in the default group selected in DEP.
Create the referenced JSON file and place it on your Web Server making sure that the security on the directory matches what you’ve specified in step 1.(2)
Upload the packages referenced in the JSON file to your Web Server.
Check to make sure packages download okay.
Write a first-boot script that launches your software installer, and gives DEPNotify the data that it needs to get things going.(3)
Test this with a Virtual Machine(4). Test it again. And again.
And Now, A Video:
This is what it’s like to setup a machine using Simple MDM, InstallApplications, DEPNotify and Munki together in a seamless toolchain:
It took approximately one full day to set all of this up and get it working like I liked, including the creation of this entry and documentation.
(1) the others are ZuluDesk and Airwatch as of the release of this post. I’ll keep this footnote updated as I hear of more.
(2) Right now, InstallApplication.py really does not like redirections, so make sure you’ve specified the correct URL.
(3) This is going to be the part that takes the longest. Building a good post setup experience for your users is going to be an interesting experience, and I think we’re going to see a lot of different takes on it based on the different schools of thought for user-focused deployment. There’s no reason that something like DEPNotify couldn’t be used over a period of hours or days to inculcate institutional culture to new staff. Play with this, It’s going to be interesting.
(4) Testing with a Virtual Machine is easily done. Using Joe Chilcote’s vfuse, create a new VM from an AutoDMG master. Open the .vmwarevm bundle and edit the .vmx file in a text editor (I recommend BBEdit) and add your Serial Number and Model Identifier. Now start your VM and you’ve got a DEP-enabled VM!
This week’s Techno Bits newsletter has a summary of the Broadcom Wi-Fi SOC exploit, some great links from Emily Kausalik and Charles Edge on macOS Sierra’s logging system, and some backstage sneak peeks into Merriweather Post Pavilion’s new stage house and the network that supports it, as well as a thank you to Walt Mossberg for his incredible career in tech journalism.
Congress has decided, for whatever reason they have chosen to represent as to why they’re acting, and frankly, none of them are too well-explained, that your Internet Service Provider can continue building a file on every site that every device on your home and work internet connection visits.
Ostensibly this is for marketing purposes – i.e., to sell those results to third parties who want to buy them in bulk – and it means that the connection that you pay for each month isn’t entirely your own.
This is, as one might imagination, a frustrating betrayal of trust, more so when you consider that we are not blessed with robust competition in most residential marketplaces, and there are few rare ISPs that can afford to stand on moral grounds against this tactic.
It used to be that you could opt out of the “super cookie” Unique Identification Headers (UIDH) that companies like Verizon are already appending to your HTTP Requests.
Yeah, that’s sleazy. They are trying to make you, their customer, more visible to advertising partners based on your existing actions.
Thanks to aggressive lobbying of the Congress, and an abdication of any desire for an individual right to privacy on the part of Legislative and Executive branches, these communications giants are going to take a second turn at squeezing more revenue out of their networks, and they’re going to do it to their customers without so much as a discount for being their unwilling partners in marketing.
Okay, That Sucks, Now What?
So, what’s a person to do if they want to keep their surfing habits – which in many cases contain personally identifying and possibly embarrassing information – away from their ISP’s prying eyes?
There’s an easy way to help prevent their access, and that’s to use a Virtual Private Network, or a VPN. That’s a way of sending all your outbound internet traffic securely to a third party before it passes through to the internet as a whole.
What’s that look like? Think of it this way: imagine that you want to send a secret letter to a friend. You don’t want anyone in your local post office to know that you’re sending a note to John Smith in Des Moines, Iowa, so you pack up your sealed letter to John in a letter to another friend, Betty Johnson of Dubuque, Iowa, with a note to please mail this letter for you from her local post office. The post office sees that you sent a letter to Betty, but because there are rules against opening your mail, they can’t read it. Then, Betty receives your message, posts your letter to John, and no one’s the wiser.
That’s what a VPN does. It’s a secure way to send all your traffic to a third party to act on your behalf. You can securely wrap your traffic to the Internet to a third party before it gets out to the rest of the internet.
It’s not perfect, but it at least prevents some of the skeeviest trends in local ISPs. Drawbacks to using VPNs include weird results for Location searches, a performance hit to your internet speed, and perhaps the inability to view location-specific programming.
I don’t make anything from a referral to them, but I do use their product and endorse it. It’s an easy VPN to setup. Give it a try if you spend a lot of time on unencrypted Wi-Fi, or if you don’t want your ISP to have access to your surfing history.
At least two MDM vendors are going to be supporting the `InstallApplication` verb in the MDM Specification for the Mac. Why does this matter? As Apple encourages the adoption of MDM and DEP together for configuring user machines, the Munki community (and for that matter, the Puppet and Chef community) saw a path forward that didn’t include our favorite open source software installation agent. No longer.
This week’s Techno Bits Newsletter is all about reading the tea leaves, and how the work of Erik Gomez and others is looking promising for leveraging DEP and MDM with existing management systems like Puppet, Chef and Munki. Are we finally seeing the light on the horizon? Could well be.
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.
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.
When a consultant friend (Hi M!) asked what I carried with me every day, it was the first time that I’d stopped to think of everything I’ve collected over the years to carry with me on a day-to-day basis. Based on their challenge, I’ve catalogued what’s in my daily carry bag, and I present it here for you.
First up, the bag itself. I have a 2013 Timbuk2 custom messenger bag. Timbuk2 bags have two specific problems: One, they’re gorgeously designed and Two, they last forever. I’ve had a total of four since 1996, and I’ve never needed to buy a new one, I just always wanted to change up my style before the bag gave out. Better still, they have lifetime warranties, so if a part gives out, you can ship back your bag and they’ll shine it up good as new. They’re not inexpensive, but the features of the bag are substantial, and the design is wonderful. My messenger has a flap organizer in the front fascia, as well as multiple zip pockets for business cards, baseball cards, your passport, and other flat goods. The flap organizer is my catchall for small tools and keychains that I tote with me all the time.
From a hardware perspective, I carry the following:
Late 2016 MacBook Pro 15” with TouchBar, 1TB, 16GB
iPad Pro 12.9” with Apple Pencil
iPhone 7 Plus (Matte Black)
The MacBook Pro and iPad ride back to back in the padded laptop sleeve in the center of the bag, and the iPad behind in the protected position.
Inside my bag itself I have a couple of organizers that serve as containers for primary work tasks, and they keep the contents protected and clearly identified and organized in case I need them. The bigger of the organizers is a Skooba Cable Stable DLX, with multiple mesh pockets to allow easy visibility into the contents, and elastic tension loops to hold the contents in place.
Contents, Left Side:
Mini DisplayPort to DVI Adapter
USB-C to Lightning cable – 2-meter
USB-C to USB-C charging cable – 2-meter
27W USB-C Charger
Diskwarrior USB Drive
OWC Envoy Pro Mini USB Drive
Contents, Right Side:
Lightning to 3.5mm adapter
Paracord USB-A to Lightning Cable
Thunderbolt 2 to Gigabit Ethernet Adapters (2)
USB-A to USB Micro Cable – 6-inch
Netool Smart Network Terminal
USB-C to Lightning Cable – 2-meter
Belkin USB-C to Gigabit Ethernet Adapter (2)
Thunderbolt 3 to Thunderbolt 2 Adapter
Contents, Center Spine Loops:
USB-C to USB-A Adapters (2)
I don’t have a lot of notes on this set, except to say that extras are always welcome, especially when you think about all the times your clients need something, and you just supply it out of clean blue air, and replace it later.
In addition to my primary organizer, I also keep a smaller Cable Stable Mini outfitted with my SpecAn gear. This includes a full Metageek set, including a WiSpy DBx for peeking at the 2.4 and 5 Ghz spectrum in their entirety, as well as a Linksys AE2500 USB WiFi stick for use with Channelyzer in my Windows VM (Windows VMs on the Mac can’t talk too the AirPort interfaces, we just get a raw network socket, so this is our workaround) as well as the USB-A to USB Mini interface. In the pocket I keep the antenna and hook. Sometimes I throw the Oscium Lightning-based SpecAn in this as well, but most times it’s loose in the pocket.
And then there’s everything else! This list starts at the upper left corner and works clockwise:
Thunderbolt 2 cable, 2-meter
Field Notes notebook
USB 3 SANdisk Extreme
Code 42 branded microfiber cloth
OLALA 13000mAh battery
PSUMA-branded 4000mAh backup battery
sticky-backed velcro strips
RJ-11 and RJ-45 jack ends
Sugru moldable plastic
Pentalobe and Tri-wing screwdrivers
Gotenna bluetooth radio for texting when there’s no cell service
That’s a look inside my daily carry. It’s pretty amazing how much stuff I tote around on a daily basis.