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.
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:
Being able to authenticate with domain credentials for doing things that require admin privileges.
Being able to connect remotely using domain credentials.
Computer labs and other multi-user Macs.
We’re still using AD mobile accounts, for now.
Originally, we would bind Macs to AD as part of our DeployStudio imaging workflow. Unfortunately, we faced a couple of drawbacks with this approach:
By installing/configuring something only when imaging, you’re not enforcing the setting – it’s a one-shot thing. In the future, the setting could change, or the application might require an update, but you’re not going to reimage your entire fleet every time that happens.
When we moved from DeployStudio to Imagr, we needed to trim our workflows to be as slim as possible.
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.
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.
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.
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) SQUIRREL_TLS_CERT (/path/to/cert.pem) SQUIRREL_TLS_KEY (/path/to/privkey.pem)
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.
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?
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
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.
A year ago, we were first getting started with Munki – and deploying Adobe’s Creative Cloud applications was an important goal in our effort to move towards modular deployments. Using Adobe’s Creative Cloud packager, I made individual packages. For some people, we deployed individual apps, but for others, I created manifests that resembled CS6-style “suites.” It worked, and I moved onto other tasks.
We have been deploying the same Adobe CC packages from June 2014 until now. There have been requests for newer versions of these applications, but building newer packages was a significant amount of work – especially because Adobe’s installer packages are randomly broken in a number of different ways.
Recently, Nick McSpadden documented a significantly better method of deploying these apps on the Munki wiki, along with their updates (imported with Tim Sutton’s aamporter). He tested the uninstallers, too, and wrote his own when they didn’t work properly. He also wrote an excellent blog post to further assist Munki administrators in adding the proper metadata for all of the Adobe applications.
Here’s my contribution.
System Requirements
When importing these packages into Munki, I noticed most, if not all, had incorrect OS requirements set in the pkginfo files. In the interest of simplifying things, I set all of our Adobe packages to require OS X 10.9.5. When Creative Cloud 2015 is released, it seems that will be the requirement anyway.
PDF Browser Plugin
We’ve had some difficulty in the past with Adobe’s PDF browser plugin. Even though we have an enterprise site license for all of the CC applications, we found with Acrobat 11 that if Acrobat hadn’t ever been launched, and the user viewed a PDF file in their browser, they’d receive an error message about needing to agree to the EULA. Launching Acrobat never displayed a EULA, but it got rid of the browser plugin’s message. This is unacceptable, especially in our computer labs. Originally, our solution was to move the browser plugins to another folder – that way, the user could move them back if they wanted. In practice, though, we found it easier to delete the plugins entirely.
We’re pushing a package called “removeadobepdfplugin” with the following postinstall script:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It’s set as an update_for the Acrobat package, and also has this installcheck_script:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At the end of Nick’s blog post, he mentions Pepijn Bruienne’s suggestion to grab the app descriptions from MacUpdate. Since MacUpdate’s descriptions were incomplete and some needed editing, here are all of the descriptions we’re using:
Acrobat Pro DC
Adobe Acrobat Pro DC with Adobe Document Cloud services is here. Completely reimagined PDF tools let you create, edit, sign, and track PDFs from anywhere. It will change the way you work with design layouts, press-ready files, and all your important documents forever.
After Effects CC 2014
The new, more connected After Effects CC 2014 can make the impossible possible. Get powerful new features like a Live 3D Pipeline that brings CINEMA 4D scenes in as layers – without intermediate rendering. Share work directly from within the application and get access to new features the moment they’re released. Your entire creative world, together in one place.
Audition CC 2014
Adobe Audition CC 2014 empowers you to create and deliver beautiful audio using more connected tools and dozens of new features, including Sound Remover, which can eliminate unwanted sounds from an entire file just by analyzing a small selection. Adobe Audition CC gives you access to new features as soon as they’re released and is integrated with other Adobe video tools for smooth start-to-finish audio and video production. Your entire creative world, together in one place. Only in Creative Cloud.
Bridge CC
Adobe Bridge CC provides you with centralized access to all the media assets you need for your creative projects. Batch edit with ease, add watermarks, and even set centralized color preference — Bridge simplifies your workflow and keeps you organized.
Dreamweaver CC 2014
Adobe Dreamweaver CC 2014 allows you to design, develop, and publish for web and mobile platforms without getting buried in code. Dreamweaver provides an intuitive visual interface for website creation and editing, and offers up-to-date compatibility with web standards as well as first-class support for HTML5/CSS3 and jQuery.
Edge Animate CC 2014
Edge Animate gives web designers the tools they need to add motion to web graphics and create interactive content on their sites, while assuring that their designs display consistently across mobile devices, tablets, and modern browsers.
Edge Code CC
Adobe Edge Code CC is a lightweight code editor for web developers and designers working with HTML, CSS, and JavaScript. Edge is built to work with browsers, speeding up development time by displaying changes to the code directly on the screen.
Edge Reflow CC
Edge Reflow CC enables designers to build beautiful responsive web designs. Create on a native web surface with CSS design and layout features in a familiar and intuitive way. Preview and share your designs on-device through the integrated Edge Inspect plugin. Communicate your website’s responsive behavior and intent, ensuring your design vision isn’t compromised.
ExtendScript Toolkit CC
Access a rich JavaScript development and execution environment to use directly with scriptable Adobe desktop applications. The ExtendScript Toolkit works with many Creative Cloud applications.
Extension Manager CC
The Adobe Extension Manager provides an easy and convenient way to install and delete extensions in many Adobe applications, and to find information about extensions you’ve installed. It also provides a convenient way to navigate to the Adobe Exchange site, where you can find more extensions, get information about extensions, and rate extensions that you’ve used.
Fireworks CS6
Adobe Fireworks CS6 software helps you create beautiful designs for websites and mobile apps in a snap, without coding. Deliver vector and bitmap images, mockups, 3D graphics, and interactive content for popular tablets and smartphones.
Flash Builder Premium
Adobe Flash Builder Premium software is an Eclipse based development tool for rapidly building standout mobile, web, and desktop applications using ActionScript and the open source Flex framework. Use professional testing tools to build higher performing applications.
Flash Professional CC 2014
Flash CC 2014 lets you share work directly from within the application and get access to new features the moment they’re released. Your entire creative world, together in one place. Work faster than ever before with a 64-bit architecture, a new streamlined user interface, and more connected tools. Create HTML content and export high-definition video and audio.
Gaming SDK
Essential set of tools to rapidly build, optimize, and deliver your games to different platforms and devices. These are used by more than 3 million developers across the world.
Illustrator CC 2014
Adobe Illustrator CC 2014 is the industry standard vector-drawing environment for designing across media. Express your creative vision with shapes, color, effects, and typography. Work with speed and stability on large, complex files, and move designs efficiently among Adobe’s creative applications.
InCopy CC 2014
Adobe InCopy CC 2014, ideal for large team projects involving both written copy and design work, provides copywriters and editors with a powerful tool to style text, collaborate through track changes, and make simple layout modifications that integrate effortlessly with InDesign.
InDesign CC 2014
Adobe InDesign CC 2014 is part of Creative Cloud. That means you have access to all the latest updates and future releases the moment they’re available. Sharpen your skills and master new tools with a rich and growing library of training videos. And Creative Cloud is integrated with Behance, so you can share your projects and get immediate feedback from creatives around the world.
Lightroom CC 2015
Adobe Lightroom software helps you bring out the best in your photographs, whether you’re perfecting one image, searching for ten, processing hundreds, or organizing thousands.
Create incredible images that move your audience. Experiment fearlessly with state-of-the-art nondestructive editing tools. Easily manage all your images. And showcase your work in elegant print layouts, slide shows, and Web galleries, as well as on popular photo-sharing sites. All from within one fast, intuitive application.
Media Encoder CC 2014
Adobe Media Encoder CC software automates the process of creating multiple encoded versions of source files, Adobe Premiere Pro sequences, and Adobe After Effects compositions. An intuitive interface, background encoding, and convenient presets help you quickly output for virtually any screen. Adobe Media Encoder is included in Adobe Premiere Pro, After Effects, and Adobe Prelude software.
Muse CC 2014
Adobe Muse enables designers to create websites as easily as creating a layout for print. Design and publish original HTML pages using the latest Web standards, and without writing code. Now in beta, Muse makes it a snap to produce unique, professional-looking websites.
Photoshop CC 2014
Adobe Photoshop CC, the industry standard for digital image processing and editing, delivers a comprehensive package of professional retouching tools, and is packed with powerful editing features designed to inspire.
Prelude CC 2014
Adobe Prelude CC software streamlines your production tasks. Ingest nearly any file-based format and begin logging immediately, creating searchable markers and other temporal metadata that flow through post-production, so you can work faster and stay organized. Adobe Prelude is included in Production Premium, Master Collection, and Creative Cloud.
Premiere Pro CC 2014
Adobe Premiere Pro CC 2014 lets you edit video faster than ever before. Dozens of brand-new features include a redesigned timeline, improved media management, and streamlined color grading. And it’s just the beginning: You’ll get access to new features the moment they’re released. Your entire creative world, together in one place. Only in Creative Cloud.
Scout CC
Adobe Scout is a lightweight but comprehensive SWF profiling tool designed for Flash game developers. Any SWF file, regardless of whether it runs on mobile devices or in browsers, can be quickly profiled with no change to the code, and Adobe Scout quickly and efficiently detects problems that could affect performance.
SpeedGrade CC 2014
Adobe SpeedGrade CC 2014 lets you deliver balanced color and distinctive, vibrant looks for any type of video production. Grade faster with more connected tools, over a dozen powerful new features, and a redesigned interface that’s both intuitive and familiar for Adobe Premiere Pro users. SpeedGrade CC gives you access to ongoing updates as soon as they’re released, and integrates with other Adobe video tools for smooth start-to-finish video production. Your entire creative world, together in one place.
Adobe Utilities
When reading about Extension Manager, Media Encoder, and ExtendScript Toolkit, I found that they’re typically bundled with particular apps. Great! I can use Munki’s ‘requires’ key, rather than including these utilities in manifests.
After Effects Bridge Illustrator InDesign Photoshop
Since Extension Manager is related to ExtendScript Toolkit, I’ve also added these apps to the previous list:
Dreamweaver Flash Professional InCopy Prelude Premiere Pro
Now, when any of these apps are installed, they’ll automatically have the appropriate utilities installed along with them.
Edge Code
After packaging it up, I launched Edge Code to see a message that it’s been replaced by Adobe Brackets as of November 2014. Thanks to Jason Stanford, there’s already an AutoPkg recipe for Brackets – that’s one fewer Adobe package you’ll need to create.
There are a number of ways to set preferences on OS X. To name a few:
Local MCX
Modifying the User Template
Configuration Profiles (.mobileconfig files)
However, each has a drawback:
Local MCX is rumored to be deprecated in favor of Configuration Profiles.
The User Template exists in /System, which is generally understood to be owned by Apple. OS updates can (and will) replace files in the User Template folder, potentially breaking your changes or causing login issues.
Although useful, Configuration Profiles can be extraordinarily difficult to work with.
Enter: scriptRunner, by Nate Walck. We’ve been deploying this for a couple of months, and it’s helped significantly. Just script what you want to happen at login, decide if you want it to happen once or at every login, then install your script in a specific location. Combined with dockutil, we’ve managed to transition most of our Local MCX settings to Bash scripts (which are pushed out via Munki).
Some settings were difficult to reimplement, though: for example, we wanted to disable Wi-Fi on our lab iMacs – they’re already connected via Ethernet, so there’s no reason for Wi-Fi to be enabled. With Local MCX, we had the ability to disable specific network interfaces, but that’s not possible with Configuration Profiles. What do we do?
Joe Chilcote’s outset proved to be exactly what we needed. Besides adding logging functionality, outset improves upon scriptRunner in that it can:
Install packages at first boot
Run scripts at first boot
Run scripts at every boot
Run scripts at first login
Run scripts at every login
Therefore, our solution was to run a script at every boot that disabled Wi-Fi.
At the moment, the Macs on campus are running a range of 10.6.x to 10.9.x. Since outset has only been tested on 10.9.x, we’re pushing scriptRunner to Macs running 10.6.x to 10.8.x, and outset to Macs running 10.9.x. scriptRunner’s paths have been changed to match outset’s, so we can push the same scripts to both.
