As I’m reorganizing my GitHub repositories, I’ve realized that I forgot to post about my work with Shea Craig and the JMP Team at SAS. Because of them, I was able to deploy JMP Pro 12.x and 13.x licenses to our Mac labs.
One of the most powerful features of Munki are conditional items – and the ability for an admin to provide custom conditions for deploying or removing software. For example, we’ve been using the scripts that Hannes Juutilainen has published to determine which macOS version is supported by a particular Mac’s hardware. We can then offer the most appropriate OS upgrade to each Mac.
We recently deployed the excellent NoMAD to single-user Macs, with the intention of resolving keychain issues (and eventually moving away from Active Directory binding altogether). If you’re using AD with your Macs, it’s absolutely worth checking out.
When a user logs into NoMAD, some data about the user’s AD account is retrieved for later usage – such as their group membership (also known as Organizational Units, or OUs). In our environment, users are divided into different groups based on their department. What if we could use that for deploying printers, similar to Group Policy on Windows?
You might see where I’m going with this – check out the script on GitHub for requirements and usage instructions.
For our April 2017 Greater Philadelphia Mac Admins meeting, I presented on Munki 101. Here’s the summary (along with the slides), and here is the video:
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
managedsoftwareupdate has several methods you can use to identify your Macs to your Munki server. While the hierarchy is documented on the Munki wiki, the ComputerName field (accessible in System Preferences –> Sharing), is not one of them. Since our inventory system is tied to the computer name, we wanted Munki to use that as the identifier for manifests, too.
I wrote a small LaunchDaemon and script to write the ComputerName field to Munki’s ClientIdentifier field (which overrides the hierarchy mentioned above) each time it’s changed. This allows IT to rename Macs and manifests as needed, but also audit unauthorized computer name changes through MunkiReport.
The code is available on my GitHub repository.
I’m not sure how I hadn’t posted about this yet, but I help organize a local meetup group for Mac / iOS admins, called Greater Philadelphia Mac Admins. We meet monthly – if you’re in the area, you should consider attending! The meetings are free, and dinner is provided.
For more information, please see our website.
Also, I presented on Munki a few months ago, at the October 2015 meeting. Check it out!
Like most things, Boot Scheduler was written to scratch an itch: students were powering off lab computers, which could stay off for weeks or months at a time (particularly in the smaller labs). These Macs would stop checking in to Munki, would be horribly out of date, and would behave unpredictably once powered on again – the AD binding could become broken, or they might reboot unexpectedly to apply security patches.
We discussed using the built-in pmset tool to power on all Mac labs daily, but we have a long winter break – we don’t want these Macs turning on and wasting energy without anyone around to use them. Since pmset has no concept of calendar dates beyond days of the week, we had to develop something custom.
My hope is that if you’re facing similar issues, Boot Scheduler can help you. You can grab it from my GitHub repository – be sure to check out the README for installation and customization instructions.
I’ve overhauled my scripts for backing up VMware Fusion images with Carbon Copy Cloner. Now, the currently running VMs are paused, backed up, then unpaused. Pausing/unpausing does not save the contents of the VM’s RAM to disk, so I’ve also added support for suspend/resume.
You can get the updated scripts in my GitHub repository.