I had the honor of presenting at the University of Utah’s May 2021 MacAdmins Meeting this week.
The slides and video are already up – check them out here!
This is the second post in my multi-part series on modern bootstrapping with Workspace ONE UEM. If you haven’t read the first one, you can find it here.
For a while now, I’ve been meaning to post about how I’m bootstrapping our Macs using Workspace ONE UEM and several open source tools. This will be a multi-part series, and will culminate with a presentation at the University of Utah’s MacAdmins meeting for May 2021. I feel that it’d be best to start with some historical context and how bootstrapping has evolved since I joined the industry.
In several previous posts, I detailed how to secure various services with a Let’s Encrypt certificate, installed in DSM. I approached each one individually, figuring out how to link the certificate in a way that each application accepted.
On my post about securing Ubooquity, jcd suggested I use Synology’s built-in reverse proxy server instead (and linked to this tutorial). Honestly, this was the best advice, and I’ve since switched away from the various methods I detailed before. Please check out Graham Leggat’s tutorial – this post isn’t meant to be a retelling, but hopefully adds some useful notes that I learned along the way.
Essentially, here’s how a reverse proxy works: you have a service running inside of your firewall over HTTP (not secured). Here are some of your options for opening that service outside of your network:
A reverse proxy is a separate server, sitting in between your service and the internet, which will encrypt all traffic, seamlessly. When you connect from outside of your firewall, you’ll communicate securely to your reverse proxy, which will then pass along your traffic to your unencrypted applications.
There are many benefits to this approach: this works with nearly every application, requires very little configuration (past the initial setup), allows you to set up memorable URLs without using weird ports, etc.
Now that you’ve got all of that squared away, let’s proceed.
https://application.yourdomain.comin a web browser. If you did everything right (and I didn’t miss any steps!), you should be able to load your application and see that the connection is secure. If you click the lock, you should see your wildcard certificate.
Going forward, you can do this for multiple applications – and each one can use port 443, so you don’t need to open additional ports outside of your firewall or remember anything more than your unique subdomain for each application.
Ever since I got my MacBook Pro with a Touch Bar, I’ve avoided typing in my password as much as possible. macOS 10.14 and 10.15 added more places in the OS that accept Touch ID, which has been a welcome change. As part of my job, I tend to use the
sudo command quite a bit, and this post from Rich Trouton has been a godsend. Just edit the appropriate file, restart your Terminal session, and you’re all set.
However, with many macOS patches and security updates,
/etc/pam.d/sudo is reset back to defaults. I don’t know why this happens, but it’s quite annoying. After manually applying the change to this file again, I finally decided to script it.
Now, there are a handful of files that can really ruin your day if they become damaged or invalid. This is one of those files. Please proceed with caution, keep good backups, and be prepared to reinstall your OS if things get really messed up. That said, this worked for me on macOS 10.15.5, and will hopefully continue to work for years to come.
Since I use Munki, I decided to build a nopkg file that checks for the appropriate line in
/etc/pam.d/sudo, and inserts it if it’s not present. To download the code, please see my GitHub repository.
Last spring, my fiancée and I bought a house. We lived in an apartment for two years, and experimented with smart home stuff, but wanted to do a bit more with our house. We’ve had enough people ask about our setup that I figured I’d write a blog post.
If you’re new to this stuff, you’re probably overwhelmed by the competing (and often overlapping) technologies that are out there. Between Apple Home / HomeKit, Google Home / Nest, Samsung SmartThings, Amazon Alexa, IFTTT, etc., it gets confusing very quickly (though it sounds like that will get better eventually). In our case, we made the decision to go with Apple Home / HomeKit – I’m not crazy about Google and Amazon’s invasive privacy practices, even if their voice assistants are better for it. Since we have iPhones, iPads, and Macs, Apple’s standard made the most sense for us.
First, we bought a bunch of Belkin WeMo Mini smart plugs. We’ve attached these to various appliances: lamps, humidifiers, noise machines, etc. They’re great for anything that resumes whatever they were doing when you unplug, then plug them back in. They didn’t support HomeKit at first, but a firmware update added that later.
For rooms that had built-in lighting, we bought a WeMo Dimmer Switch and a WeMo Light Switch. The dimmer switch received HomeKit compatibility via a firmware update, but the light switch required a new model – so be sure to get the second generation switch. Note that these require a neutral wire, so if your house’s electrical wiring is very old, you should check before buying – we weren’t able to use these everywhere, unfortunately.
For the front door, we bought a Yale Assure Lock, along with an indoor handle. We chose this model specifically because of the keypad (you can generate an unlimited number of codes and expire them whenever you want), the ability for it to auto-unlock as you approach the door, and the ability to auto-lock. You can receive notifications whenever the door is locked and unlocked, too. Some models do not have physical keys, but we wanted one in case the batteries died or the lock malfunctioned.
For the side door, my brother Paul gave us his August Smart Lock Pro, which we used with the standard deadbolt we installed last spring. This integrates with the same app we use for the front door, as well as HomeKit.
We also replaced the thermostat with a Honeywell Lyric T5+. Replacing the thermostat was surprisingly easy, and gave us immediate benefits: we can control the thermostat from anywhere, set up a geofence so it turns back the heating/cooling when we’re not home, and schedule times for different temperatures. Its HomeKit support hasn’t been the best – we’ve found that it will drop off of HomeKit, but not the Wi-Fi, so we know it’s not completely offline. We’ve considered replacing it with an Ecobee thermostat, which includes extra sensors for around the house – maybe in the future.
Outside, we bought a few Arlo Pro 2 cameras. Initially, these didn’t support HomeKit, but Arlo added support via an app update. Each Arlo camera appears in HomeKit as both a camera and a motion sensor. They run completely on batteries, so you’ll need to take them down every couple of months to charge them. This gives you a lot of freedom to mount them where they’re needed, though – you don’t need to plan around outdoor outlets. A big selling point was the free 7 days of recording, though we upgraded to a paid plan for more storage and notifications with video previews. Initially, we used the magnetic outdoor mounts, but switched to the Wasserstein Arlo Mounts instead – that way, when we take down the cameras for charging, we don’t need to do so much adjusting when we put them back up.
Although we use Spotify for music, we found that having various devices that can play music – TVs, sound bars, individual speakers, laptops – made for an inconsistent experience. A few months ago, prices dropped on Sonos One speakers, and we bought one out of curiosity. Long story short, that grew to a full house of Sonos speakers. It really helped that Sonos and IKEA have a partnership, so we picked up several SYMFONISK bookshelf speakers, as well as a couple of SYMFONISK table lamps. We even mounted a Sonos One in the bathroom with a ALLICAVER wall bracket. It’s very hard to describe the feeling of whole-house audio, but it’s pretty neat to walk from room to room and your music is playing everywhere. Every speaker supports AirPlay 2 and HomeKit, though we’ve found the Sonos and Spotify apps to be more reliable for queueing up music.
After buying a couple of SYMFONISK table lamps, we realized that we’d need smart bulbs. Up until this point, we’d managed to use the WeMo switches with standard LED bulbs, but cutting power to the SYMFONISK table lamps would mean no music. At first, we tried IKEA’s TRÅDFRI, but found their bulb selection to be very limited – we didn’t want to buy into a system that would only be useful for two lamps. This brought us to the Philips Hue bulbs.
I could write an entire post about Philips Hue alone, but in short: we’ve been very happy with it. There’s a wide selection of options, which is great, but also intimidating. They make smart bulbs in every size, so they’re flexible enough that you can expand in the future. Each bulb comes in two different types: bulbs that can switch between white/yellow light, and bulbs that support colors like red, blue, green, etc. For our case, we’ve found that the white/yellow bulbs have been fine for us, and haven’t been able to justify the cost of the colored bulbs. All bulbs support dimming without the need for additional hardware.
It helps to figure out how many bulbs you need, then buy a kit (which includes the hub) and the right amount of bulbs. You can also buy wireless buttons and dimmer switches, then pair them to any bulbs. The entire system is very flexible. Of course, everything integrates with HomeKit.
The end result is that we can tell Siri to unlock the front door, we can have all of our lights turn on when we arrive home, we can have motion sensors in the Arlo cameras turn on Philips Hue lights, and more.
Paul gave us a bunch of additional accessories that we’ve slowly integrated over the past couple of weeks, so if there’s interest, I’ll write a follow-up post. Let me know if you have any questions!
Just a quick note if you’re following this method to test Apple’s Device Enrollment Program (DEP) with VMs: as of macOS 10.14.3, the hardware must meet the minimum system requirements for macOS 10.14.
With macOS 10.14.0 through 10.14.2, you were able to use serial numbers from Macs that could not run 10.14.x themselves. Since you’re booting VMs, that didn’t really matter. However, as of 10.14.3, the VM will stall while booting, then eventually reboot and stall again.
It’s unfortunate, as older hardware is easier to find – I had a stack of 2011 Mac minis that I kept specifically for VMs.
Update, 2019-09-03: Erik Gomez corrected me: if you create a VM with vfuse, specify the 2011 Mac mini’s serial number, but use
Macmini6,2 instead of
hw_model, it’ll boot and let you proceed through DEP. I haven’t tested any other model, but this works great! Thanks, Erik.
Update, 2020-06-11: I’ve changed the code back to a script. Please see the GitHub repo for an explanation and the updated code.
Although the trend is to move away from binding Macs to Active Directory (most commonly using NoMAD), we’re still binding for various reasons:
Originally, we would bind Macs to AD as part of our DeployStudio imaging workflow. Unfortunately, we faced a couple of drawbacks with this approach:
With the help of Graham Gilbert’s tutorial, we were able to move AD binding to Munki. This also gave us an unexpected benefit: in the past, we frequently found that the binding on Macs would randomly break. This was a major issue in the classrooms, where students and faculty would not be able to login to computers and start class. Moving this to Munki with a custom installcheck_script made it “self-healing” – every 1-2 hours, Munki will rebind the Mac, if necessary (or prompt the user to do this through Managed Software Center).
For the past year, there’s been a big push to move to configuration profiles for applying settings. Luckily, you can use the “directory” payload to bind to AD! However, it’s just running dsconfigad in the background anyway, so it’s entirely possible for your Mac’s binding to be broken, but the AD profile to show as successfully installed. The MDM protocol currently has no method of determining if the AD profile should be reinstalled, so Munki is a much more logical choice for deploying this. Armin Briegel’s tutorial was instrumental in assisting with this transition.
Code and usage instructions are available in my GitHub repository.
Update, 2020-06-11: I’m now using Synology’s built-in NGINX-based reverse proxy instead. The instructions below may not work.
Continuing my series on using Docker with a Synology NAS, I now have MunkiReport v3 working – and you can, too!
Some background: MunkiReport is a companion project to Munki (which we set up with Squirrel last week). MunkiReport v3 was released recently, and has a huge list of improvements, thanks to a dedicated group of contributors – especially @bochoven and @mosen, who have overhauled large portions of the project. MunkiReport v3 has some new requirements that weren’t present with v2 – this is the perfect use case for Docker! Docker will handle all of this for us.
Briefly, here’s what we’re going to do: we’re going to set up MySQL, Adminer, and MunkiReport using Docker Compose. Then, we’re going to use DSM 6.x’s certificate and reverse proxy support to secure MunkiReport. Let’s go!
/usr/local/bin/docker-compose -f /volume1/docker/docker-compose.yml pull /usr/local/bin/docker-compose -f /volume1/docker/docker-compose.yml up -d
From there, you can create a MunkiReport installation package (I like using the AutoPkg recipe for this). Push it to your clients, then watch as they check in with sweet, sweet data.