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.
Category: Tutorials Page 1 of 2
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:
- Open it as-is, unsecured. This is generally not a good idea.
- Secure the service and open it outside of your network. You’ll need to read documentation, and possibly convert the certificate and put it in a place the application expects. Furthermore, as you open up more services outside of your network, you’ll need to open separate ports for each – it’s a lot to manage when you just want to access your service outside of your firewall.
- You can use a reverse proxy.
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.
- First, I’m going to assume you have an application/service that you want to open outside of your network, securely. Set it up on an unused TCP port. I recommend checking this list to avoid commonly used ports.
- You’ll need a domain name, and be able to add custom DNS entries.
- You’re also going to need a wildcard certificate. I paid for one, but Let’s Encrypt offers them for free, too (you’ll probably need to use this script).
- If you don’t pay your ISP for a static IPv4 address, you’ll need to set up Synology’s QuickConnect service. It’s free, but requires a Synology.com account.
Now that you’ve got all of that squared away, let’s proceed.
- First, we’ll need to forward port 443 to your Synology server. See here for instructions on how to do that for most types of routers.
- Add your wildcard certificate to DSM.
- At your domain registrar, edit the DNS settings for your domain name. Add an entry with the following:
- Value: (your QuickConnect address –
- Unless your domain name is brand new, it shouldn’t take long for your new subdomain to resolve to your Synology server’s IP address.
- In DSM, click Control Panel, then Application Portal, then the Reverse Proxy tab. Click the Create button. Fill in these details:
- Description: (name of your application)
- (don’t check any of the boxes)
- Hostname: (the local IP address of the server running your application, such as
- Port: (the port you’re currently using to access your application, such as
- Click Save, then try to access
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.
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!
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!
- Enable SSH to your Synology server. Open the Terminal and connect to your server (I’m using root, but your admin account should also do fine). Leave that open for later.
- Install Docker through Package Center, if you don’t already have it.
- Add a certificate to DSM. I like Let’s Encrypt – DSM can walk you through the certificate creation process, and will renew it automatically. You’ll need a domain name for this. You might be able to use Synology’s QuickConnect service for this. (I ended up setting up a CNAME for my QuickConnect address with a subdomain that I already own, then used the CNAME for the certificate)
- Create a shared folder for your Docker data. I named mine ‘docker’. Create two directories inside of it: ‘MunkiReport’ and ‘MySQL’.
- Create a file called ‘docker-compose.yml’ in your ‘docker’ shared folder. Populate it with this data, to start:
- Change line 41, your MySQL root password, to something random. You can also change the port numbers if you’d like, but I’m going to finish this tutorial with the assumption that you haven’t touched those (it can get confusing very quickly).
- Switch over to your Terminal window and run these two commands. The first will download the Docker images for Adminer, MunkiReport, and MySQL. The second command will create Docker containers, which contain your custom settings. If you change any of the settings in your docker-compose.yml file, re-running these commands will destroy the Docker containers and recreate them with your new specifications. Pretty cool. You can monitor all of this with the Docker application in DSM.
/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
- Now, let’s create the MySQL database for MunkiReport. Go to your Synology server’s IP address, but add :3307 to the end. You’ll reach a login page. Here are the relevant details:
- Server is your NAS’s IP address, but with :3306 at the end.
- Username is root.
- Password is whatever you set in Step 6.
- Database can be left blank.
- After you login, click ‘Create database’. Name the database whatever you’d like – I went with ‘mreport’. For ‘Collation’, pick ‘utf8_general_ci’. Close the Adminer tab.
- Open a new tab, with your server’s IP address followed by :4443 at the end. You should be greeted with an empty MunkiReport installation. Nice!
- In your ‘docker’ shared folder, you had created a ‘MunkiReport’ folder in Step 4. Inside of that, create a file named ‘config.php’. This is how we’ll configure MunkiReport – by overriding values specified in config_default.php (click to see MunkiReport’s default values). I’ll skip this part of the tutorial, as it’s documented much better on MunkiReport’s wiki. At a minimum, I’d strongly suggest setting up authentication, MySQL connection settings, and the modules you’d like to enable.
- Before you can expose your MunkiReport container to the outside world, you’ll want to secure it. You’ll do this with a reverse proxy – basically, another web server put in front of your MunkiReport container (which itself contains a web server). The reverse proxy will add encryption, but otherwise leave your MunkiReport installation alone. DSM 6.0 includes a reverse proxy, so let’s use that.
- Check out the bottom of this Synology knowledge base article. Unfortunately, the documentation leaves a lot to be desired, so I’ll suggest some settings:
- Description: MunkiReport
- Source Protocol: HTTPS
- Source Hostname: *
- Source Port: 4444
- (leave both the HSTS and HTTP/2 boxes unchecked)
- Destination Protocol: HTTP
- Destination Hostname: 127.0.0.1
- Destination Port: 4443
- Click OK to save.
- In your router, forward port 4444 (TCP) to your Synology server. If you haven’t given your Synology server a static IP address, that’d be a good idea.
- Visit your secure MunkiReport installation in a web browser:
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.
Update, 2020-06-11: I’m now using Synology’s built-in NGINX-based reverse proxy instead. The instructions below may not work.
Yep, this is another Docker blog post…but this time, we’re covering Munki!
It’s pretty common knowledge that a Munki server is just a web server. This allows tons of flexibility with hosting your Munki repository – basically anything that can run Apache, NGINX, IIS, etc. can act as your Munki server (even macOS Server, but I wouldn’t recommend it). Today, I’m going to continue the series of blog posts about Docker, but we’re going to discuss something called Squirrel.
Squirrel, written by Victor Vrantchan (@groob), is described as a simple HTTPS server for Munki. While you can set up your own Apache server (or Docker container), Squirrel comes prebuilt for hosting a Munki server.
As with Ubooquity, I’m going to use Synology DSM’s certificates. That way, we can leverage Let’s Encrypt without needing to do any additional setup.
- First, set up Let’s Encrypt with in DSM’s Control Panel. Synology has excellent documentation on that.
- Before we go any further, I’d recommend creating a directory for Squirrel to save files (such as certificates). Separately, you’ll also want to create a Munki repository (see the Demonstration Setup, but skip the Apache config stuff). If you already have a repo, that’s great too.
- Next, add the Docker image for micromdm/squirrel. Follow Synology’s instructions.
- Create a Docker container, following those same instructions.
- You’ll want to specify two volumes, both of which you created in Step 2: where to store Squirrel’s data, and your Munki repository. I have a shared folder named ‘docker’, and I like creating directories for each service within that: for example, /volume1/docker/Squirrel. I made a ‘certs’ directory within that, as well.
- You’ll also want to pick a port. If you’re comfortable exposing port 443 to the world, go for it. Otherwise, use 443 internally to the Docker container, and pick another port for the outside world. Be sure to forward this port on your router!
- The environmental variables you’ll want to override are:SQUIRREL_MUNKI_REPO_PATH (this is the path to your Munki repo, which you specified in Step 4a).
SQUIRREL_BASIC_AUTH (this is a randomly generated password for your Munki repo)
- But wait, where do we get the cert? I wrote a really simple script to copy the Let’s Encrypt certs to Squirrel’s config location: get it here. Be sure to edit line 6! I run this once a night, with DSM’s Task Scheduler.
- After you start up your Squirrel container, check the Docker logs by selecting your container, clicking the Details button, then the Log tab. You’ll see the Basic Authentication string that you’ll need to provide to your Munki clients. You can find out more information on the Munki wiki.
After that, you’re done! Your clients have a secure Munki repo, and you don’t have to bother with Apache config files, a reverse proxy for securing your web server, or any of that.
Update, 2020-06-11: I’m now using Synology’s built-in NGINX-based reverse proxy instead. The instructions below may not work.
Whew, that’s a very specific title. I don’t know if this will be useful to anyone else, but it took a fair amount of work to figure it out, so I figured I’d document it. There will be more Mac stuff soon, I promise!
If you haven’t heard, Let’s Encrypt is an excellent service, with the aim of securing the internet by offering free HTTPS certificates to anyone who requests one. In fact, I’m using one on this website right now. 🙂
With DSM 6.0, Synology added the ability to request a free certificate from Let’s Encrypt to secure your NAS. DSM handles renewing your certificate, which must happen every 90 days (one of the limitations of the free certificate, but nothing that can’t be automated).
Unrelated for the moment, but I’ve been using Ubooquity (through Docker!) for the past few months, and it’s been pretty neat. You can point Ubooquity to a directory of ePub and PDF files, and it’ll allow you to access the files remotely using reader apps like Marvin, KyBook, or Chunky. I have a habit of buying tech books and comics through Humble Bundle sales, but transferring the files to my iPad through iTunes/iBooks is clunky and requires a fair amount of disk space upfront.
Although Ubooquity supports user authentication, you’ll want that to happen over HTTPS, to keep your passwords secure. Luckily, Ubooquity supports HTTPS, but requires the certificate (and other associated files) to be in a format called a “keystore”. What?!
Here’s how to leverage DSM’s Let’s Encrypt support to secure Ubooquity, automatically.
- First, you’ll want to set up Let’s Encrypt in DSM’s Control Panel. See Synology’s documentation.
- Next, you’ll want to get Ubooquity up and running (I recommend the Docker image mentioned above). Synology’s documentation covers that, too. If your eBook library is a mess Calibre will make quick work of that.
- For this to work, you’ll also need the Java 8 JDK installed. This will give you access to the ‘keytool’ command you’ll need to create your keystore. Once again, see Synology’s documentation.
- Now, you’ll put all of this together. In a nutshell: you’re going to use the Let’s Encrypt certs that DSM has helpfully obtained for you, convert those to a keystore, put the keystore in Ubooquity’s config directory, and tell Ubooquity to use it to secure its interface. Here’s a script to get you started – note that you’ll need to edit lines 11, 12, and 15 for your environment. Thanks to Saltypoison on the Ubooquity forums for most of the code that became this script!
- Once you’ve successfully run the script, I recommend using DSM’s Task Scheduler to have it run once a day. This way, Ubooquity’s certificate will always be up to date with DSM’s certificate. That’s right, I’m going to link you to Synology’s documentation.
- Finally, you’ll need to tell Ubooquity where to find your keystore. Login to the Ubooquity admin interface, then click the Security tab. You’ll see two boxes – one for the path to your keystore, and one for the keystore password. Enter both. Click ‘Save and Restart’ at the top-right corner.
- Now, try accessing your Ubooquity instance using https and your FQDN! If it doesn’t work, make sure you’re forwarding the appropriate ports from your router to your Synology server – you’ll need to do this for both the eBook interface, and the admin interface (which are accessible via two different ports).
I’ll probably post more Synology/Docker stuff in the future, as I’ve been spending a lot of time with both. They’re really awesome!
This post has been brewing for a while, and a MacEnterprise thread from today finally got me to write about this problem, and how we resolved it.
Our university has many computer labs – some in public, open spaces, and some in classrooms. Although we don’t use roaming profiles (a technology that Apple finally removed in macOS 10.12), we do bind to Active Directory and create mobile accounts upon logging in with a valid AD account. To prevent the buildup of cruft, we remove student and faculty accounts periodically. In the public labs, we do it overnight, using a script based off of this one from Marnin Goldberg:
The most important parts of that script are:
# Delete the account
/usr/bin/dscl . -delete $a
This deletes the cached Active Directory account from the system.
# Delete the home directory
/bin/rm -rf $a
This deletes the home folder, freeing up space for more accounts.
We noticed something strange, though. After a couple of weeks of usage, the iMacs in our public labs would freeze at random points: at boot, at login, when using applications, when logging out, even when shutting down. Here’s a list of things we noted while trying to resolve the issue:
- We use Munki to deploy software, so one by one, we removed potential culprits from the manifests. Eventually, we whittled down the manifest items to three things we could not remove from this particular lab: Microsoft Office, the Xerox printer driver, and Active Directory binding.
- We investigated if this was an issue with our network, power, or Active Directory setup. For a few weeks, all iMacs were plugged into UPSs.
- We replaced all of the iMacs with brand new models – some with SSDs, and some not.
- As this issue persisted over ~3 years or so, we tested against multiple macOS versions – including 10.9, 10.10, and 10.11 (and the minor versions in between).
- We enabled OD debug logging, but couldn’t make much sense of the logs. They were very, very verbose.
- Ultimately, the best fix was to reimage the Mac. This would hold off the freezing for at least another week or two.
- The freezing seemed linked to computer usage. If an entire lab was reimaged at the same time, the first Macs to freeze were located near the printers. During the summer, when usage was decreased, we rarely had reports of freezing issues in the public labs.
We were in the process of reaching out to our Apple Systems Engineer, when we found a long-running thread on Jamf Nation, detailing the exact problems we were facing. It was a relief to see others were trying similar tactics, too. Then, towards the bottom of the thread, Frank Kong noted that with every use login, some files were being left behind – and the script we were using did not clear those out. In System Preferences > Sharing > File Sharing, you could see a long list of shares, all named things similar to “Mike Solin’s Public Folder”. Bingo, there’s our culprit.
Alan Petty, in the same thread, added this code to his profile deletion script:
/usr/bin/find /private/var/db/dslocal/nodes/Default/sharepoints -name "*" -type f -delete
/usr/bin/find /private/var/db/dslocal/nodes/Default/groups -name "com.apple.sharepoint*" -type f -delete
We found this code can be run while a user is logged in, so we don’t need to exclude the current user from this part of the script. It will, however, delete all file shares present on the computer (whether they are for public folders or not). This isn’t an issue in our labs, but it’s still worth mentioning.
We’ve had this fix in production for just over a month, and I can safely say the freezing problems haven’t returned.
Long-term, it might be best to look into deleting profiles using a configuration profile – Marnin posted his here. For now, we’re sticking with the script, as it gives us more control over where and when it runs.
As a sequel to the first post I made to this blog, I’ve found myself tackling this same thing with every macOS release. Today, however, I discovered a line in /private/etc/sudoers that I hadn’t noticed before:
## Read drop-in files from /private/etc/sudoers.d
## (the '#' here does not indicate a comment)
After some research, I discovered that you can drop a file in /private/etc/sudoers.d (a directory), and, as long as the syntax is correct, it will merge those with the main sudoers file. In the event of a conflict, the last rule that applies takes effect – and, the main sudoers file is read first, so you can essentially override behavior by dropping a file into the sudoers.d directory. Awesome!
I’ve posted the working code to my GitHub repository. In the event that you want to make a change, be sure to check the file before packaging it up – or you risk breaking sudo:
/usr/sbin/visudo -csf /path/to/your/file