SI's blog about technology
If you aren't able to use an audio recording app on your iPad for whatever reason and need to resort to using the Camera app to record audio (long story), you will get a bunch of .MOV files.
So I wrote up a script that employs ffmpeg to extract just the audio from each file in a subdirectory, and then combine the separate audio files from that subdirectory into one audio file.
Script here: ExtractCombineMOVtoMP3.py
We had a couple of clients who would just never do an initial connection to CrashPlan after the upgrade from CrashPlan 4 to CrashPlan 6.5. But they would never time out or give an error message either.
Restarting the CrashPlan service didn't help. Restarting the computer didn't help. Uninstalling and reinstalling the client didn't help.
Turns out it if the detect-a-user script can't find a CP_USER_HOME, it will just keep trying to connect instead of erroring out. We modified our script, and now those clients are good (we did have to uninstall and reinstall the client after modifying the script, though).
P.S. Someone pointed out that I don't actually share the original or modified script. The point of this blog post isn't to say "Here's a script that works." There are lots of scripts that work. The point is more that if you're experiencing this issue ("connecting" and never timing out or providing an error message), you likely need to fix your script to output a CP_USER_HOME).
I had a great workflow for installing CrashPlan with Munki for older versions of CrashPlan (we were on versions 3 and 4 before).
We recently made the jump to CrashPlan 6.5, though, and that workflow no longer applies. Now you have to use a deploy.properties file instead of custom.properties and userInfo.sh files.
We had some added complications to our "upgrade" process, because our new CrashPlan server is a completely different server, and we weren't migrating everyone at once, so we couldn't just change the DNS to point to the new server. I'm not sure a jump from 4 to 6.5 would have been possible as just an installation upgrade anyhow.
So what were those complications?
Ours may be a very niche scenario (upgrading from CrashPlan 4 to CrashPlan 6.5 and not using single sign-on), but in case anyone else is in that same situation and using Munki, maybe this blog entry can save you some time in planning your rollout.
Beginning with macOS 10.13 (High Sierra), Apple is now blocking kernel extensions unless you, in recovery mode (or recovery mode–like environment), change the policy on the machine itself or use an MDM profile to approve certain KEXTs by Team ID.
One way is to install the KEXTs on a 10.13 machine, user approve them, and then check the sqlite database to see what the Team IDs are:
Here's an example of some of the output you might see:
You can use Control-D to exit the sqlite3 session.
Acknowledgements: Got commands from Enabling Kernel Extensions in High Sierra
Another way is to run this command on an existing bundle from the vendor:
For example, if you run
This approach can be helpful in fringe cases (you just need the Team ID and not the bundle ID, which may be the case, and the KEXT you're looking for has an associated bundle you can run codesign on.
Acknowledgements: Got command from MunkiReport-PHP extensions module
There is a list, actually. There's a spreadsheet that a bunch of Mac admins are sharing with each other. Unfortunately, at this point, it's a spreadsheet that anyone with the link can edit, so I wouldn't really count on that. At this point, I don't see anything malicious in there (and I haven't verified every single Team ID, of course), but I would probably play it safe and just get the Team IDs yourself. Chances are that you'll have to do it only once or twice a year at the most.
If you're using munkipkg, don't store your munkipkg files in Google Drive File Stream's mounted volume.
You may get weird permissions issues in your .pkgs or hidden files that mess up your built packages.
Usually, when you put a firmware password on a Mac, you can double-check in System Preferences > Startup Disk to see if the proper startup disk (or any startup disk) is selected.
Since the default behavior of the firmware password is you needing to enter the password in order to boot from anything other than the startup disk, you probably want to have a startup disk selected (otherwise, you'll get the folder with a question mark inside of it when you boot up).
In most cases, this isn't that difficult, but if you set up a single-boot Windows installation, you may not always see it available for selection if you boot to recovery mode or boot to macOS from an external drive.
Instead, you may want to just boot into Windows (hold down the option key and enter the firmware password if you need to this one time), and then launch up the Bootcamp Control Panel, and you can set the startup disk there.
Thanks once again to @bur on the Mac Admins Slack for the info I'm documenting here.
In a previous blog entry, I talked about using Santa to block apps by certificate (and I briefly mentioned blocking by binary).
You can also block by path using regular expressions. Binary takes precedence over certificate, which takes precedence over regex, so unfortunately you can't really block Apple apps (like Safari) using regex, because Santa automatically whitelists them by certificate—you can block them only by binary.
You may notice in the Santa documentation for configuration that both WhitelistRegex and BlacklistRegex are listed as string types instead of arrays of strings. That is absolutely true, so if you wanted to whitelist a whole bunch of app paths, you'd have to have a massively long string like this:
Same deal for a BlacklistRegex string.
If you want to create .mobileconfig profile from a certificate (for example, to import into Munki), you can use Apple Configurator 2 to do so.
If you have your certificate already in your keychain, launch up Keychain Access.app and find the certificate you want to make into a .mobileconfig profile.
Right-click the certificate and select Export NAMEOFTHECERTIFICATE (export it as a .cer).
Then launch up Apple Configuration 2.app.
Select File and then New Profile
Select Certificates and then Configure.
Find and select the certificate you exported earlier.
Select File and then Save.
Pick a filename for your .mobileconfig, which you can deploy however you want (as I previously mentioned, you can import this into a Munki repo).
Special shoutout to @bur on the Mac Admins Slack for help with some command-line syntax.
Google has a project on GitHub called Santa, which is quite powerful and complicated. As the project's readme says, though: Documentation: This is currently limited..
I just wanted to do something simple: block an app, but I didn't see any straightforward documentation on how to do that. The closest I could find was the docs on certificate rules, but that was a bit incomplete.
So, first of all, something I was confused about at first was whether a configuration profile was necessary or not. It is not necessary. There are some default settings that just go by themselves. You need to configure settings only if you need to configure settings.
If you have a blocking application rule, you can block by binary or by certificate. By binary may not be as helpful, because newer versions of an app will be a different binary. Let's say you want to block MacKeeper by certificate. (Install Santa first, so you can actually use it, including the santactl command.)
Then, add a block rule for it:
You can always check on the other parameters by running
If you then try to run MacKeeper, you'll get a block message like this: 
That's pretty much it. That isn't everything Santa can do. That's about the simplest thing you can do with Santa, but most of the documentation for Santa is about all of the other stuff you can do. I didn't see much about just how to simply block an .app, hence this blog post.
If you notice that running munkiimport on a .dmg doesn't result in an installer_item_hash generating, you might want to also run makepkginfo on that .dmg to double-check it's read-only: