Categories
Mac admin'ing

Fix for VirtualBox Extension Pack postinstall script hanging in Munki

The problem

If you’ve been running the VirtualBoxExtPack.munki.recipe AutoPkg recipe, and you’ve noticed the VirtualBox Extension Pack postinstall script in Munki hanging indefinitely (30 minutes and beyond), it’s because the license hash has changed.

The fix

According to @jessepeterson (the maintainer of that AutoPkg recipe), the license hash doesn’t change very often, but it did change, and @lctrkid made a pull request (now merged in) on that recipe repo to put in the new license hash, so you may have to run a autopkg repo-update jessepeterson-recipes and then possibly re-create the recipe override or manually add the license part of the override.

Some background

The license hash is something you can find by manually running a command like this (with the actual extension pack in your Downloads folder, of course): sudo /usr/local/bin/VBoxManage extpack install --replace ~/Downloads/Oracle_VM_VirtualBox_Extension_Pack-6.1.14.vbox-extpack. It will display the whole license, and then prompt you to accept the terms: Do you agree to these license terms and conditions (y/n)? y

Once you’ve accepted, you will then see the hash:

License accepted. For batch installation add
--accept-license=33d7284dc4a0ece381196fda3cfe2ed0e1e8e7ed7f27b9a9ebc4ee22e24bd23c
to the VBoxManage command line.

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully installed "Oracle VM VirtualBox Extension Pack".

Acknowledgements

Special thanks to @lctrkid and @jessepeterson on the MacAdmins Slack for helping understand what’s going on.

Categories
Mac admin'ing

If Jamf recon is launching a du process that causes a CPU spike

If Jamf inventory (jamf recon) causes an extended CPU spike specifically related to the du command, you can fix that by going, in the Jamf settings, to Computer Management > Computer Management – Management Framework > Inventory Collection, and then uncheck the Include home directory sizes checkbox.

That is a system-wide setting, but especially if most or all of your fleet is one-to-one Macs (not shared Macs), it’s a good idea to do. Your jamf recon inventory runs will still report back free disk space, just not broken down by individual home directories.

Special shoutout to tlark and neilmartin83 on the MacAdmins Slack for giving me more context around this.

Categories
Mac admin'ing

Fixing DEPNotify GUI not launching with keyPath error

I’m not sure how my computer got into this funky state, but I was playing around with a DEPNotify script, and after a while, I was suddenly getting these errors every time I tried to run it:

DEPNotify[12422:409983] Failed to set (keyPath) user defined inspected property on (DEPNotify.WindowController): [ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key keyPath.

DEPNotify[12422:409983] Failed to set (backgroundColor) user defined inspected property on (DEPNotify.ViewController): [ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key backgroundColor.

I tried rebooting my Mac. That didn’t make the problem go away. I tried creating a new user account, and that didn’t either. It didn’t matter whether I ran my script or just manually invoked DEPNotify with a single command. The screen would flash briefly, as if something were launching, but there was no DEPNotify window, and it wasn’t hidden or minimized.

When I did a Google search on the error, the only real results were someone not using the -fullScreen option properly two years ago and another case in which a script that starts DEPNotify just needed an update.

Unrelated to my problem (which I asked helped for but got no response), Arek Dreyer on the MacAdmins Slack (thanks, Arek!) was responding to someone else’s problem with the depNotifyReset.sh script. I didn’t run the script but tried to run the individual commands.

What ended up fixing it for me was sudo rm /var/tmp/depnotify.log and then killall cfprefsd. Then DEPNotify was functioning again!

Categories
Mac admin'ing

If your VMWare guest macOS loses network connectivity

If you haven’t changed any settings, and suddenly the Internet connection on your VMWare guest macOS installation goes out, and shutting down the VM or rebooting the VM doesn’t help, try rebooting the host Mac. That will likely fix the problem (not sure why that problem comes up in the first place.

Categories
Mac admin'ing

AutoPkg failed: hdiutil: attach failed – no mountable file systems error

If, when running AutoPkg, you get an error like

failed: hdiutil: attach failed - no mountable file systems

but you’re able to mount the .dmg manually (i.e., it’s not a corrupted download), double-check you don’t have a restrictions profile installed that requires you to authenticate when mounting disk images. That setting is pretty much useless anyway if you’re an admin user (you won’t be prompted in the GUI to authenticate when mounting disk images via Finder), and it will just make it so when AutoPkg is trying to run

/usr/bin/hdiutil attach -plist -mountrandom /private/tmp -nobrowse /PATH/TO/DOWNLOADED/DISKIMAGENAME.dmg

that it will choke with that error.

(Oddly enough, if you just do hdiutil attach without all those other options, it will still work just fine.)

Special shoutout to @elios on the MacAdmins Slack for helping another user figure this out three years ago, and so that’s how I was able to solve my problem.

Categories
Mac admin'ing

If you update an AutoPkg parent recipe, but your override is still using old settings…

AutoPkg has a cool feature called parent trust that allows you to create recipe overrides that store a hash of the parent recipe (instead of running the parent recipe directly), and then prevent you from running the recipe if there’s a change to the parent recipe, until you update the trust info. (I also have a script that runs a list of recipes, checks trust info, and prompts you to approve changes if there are changes.)

But you may sometimes run into a situation in which you see the changes, the changes are important (for example, the download URL has changed to a new URL), but even after you accept the changes and update the trust info in your override recipe, the recipe still keeps using the old URL.

Here’s an example: AndroidStudio SEARCH_PATTERN error.

So if you make an override for AndroidStudio: autopkg make-override AndroidStudio.munki, you should see something like this:
   <key>Input</key>
   <dict>
      <key>MUNKI_REPO_SUBDIR</key>
      <string>apps/android</string>
      <key>NAME</key>
      <string>AndroidStudio</string>
      <key>SEARCH_PATTERN</key>
      <string>(https\://redirector\.gvt1\.com/edgedl/android/studio/install/.+/android-studio-ide.+\.dmg)</string>
      <key>SEARCH_URL</key>
      <string>https://developer.android.com/studio</string>
      <key>VERSION_SEARCH_PATTERN</key>
      <string>https\://redirector\.gvt1\.com/edgedl/android/studio/install/([0-9.]+)/android-studio-ide.+\.dmg</string>
      <key>VERSION_SEARCH_URL</key>
      <string>https://developer.android.com/sdk/index.html</string>

Those input variables are copied over from the parent recipe. But then if the parent recipe updates SEARCH_URL to be a different URL, your override will still have the old value for SEARCH_URL.

So if you see a change to a parent recipe, and your override still seems to be using the old values, check your override for input variables, and delete the ones you don't want to override.

Categories
Mac admin'ing

Force-stopping the MunkiStatus progress bar at the login window

Sometimes, the MunkiStatus progress bar over the login window can get stuck, and pressing the Stop button can take a while to halt the progress bar completely.

To kill it immediately, press Cmd-Option-Shift-Escape (this is a slight modification of the usual force-quite key combination, which is Cmd-Option-Escape).

Full credit to Yehuda Bialik and Greg Neagle for this tip. The Wiki on Bootstrapping With Munki is now updated also to include a note this keyboard shortcut.

Categories
Mac admin'ing

Fixing Jamf device signature error

Even though this Jamf Nation thread is five years old, as of this writing, it’s still got the solution to the Device Signature Error - A valid device signature is required to perform the action error message.

In my experience, the actual working solution is to run sudo jamf enroll -prompt and then enter credentials when prompted. Repeatedly running sudo jamf recon (even after a reboot) or sudo jamf policy doesn’t fix the issue, nor does verifying that the system clock time is correct.

Now why this comes up in the first place on a freshly factory-reset computer that DEP-enrolled in Jamf—who knows but Jamf?

Categories
Mac admin'ing

Fix for custom user icons freezing up System Preferences

Even though there is some flexibility in terms of what sizes and resolutions you can use for custom user icons (to select for user pictures), if your icon’s resolution is way off, you may see a frozen blank, grey screen when trying to change the picture from that too-high-res picture to something else:

To get out of that, you’ll have to force-quit System Preferences, and then delete the picture manually with the terminal:
sudo dscl . delete /Users/username JPEGPhoto

The fix to prevent this from happening again is rather simple. Just make sure your image matches the size and pixels-per-inch that the macOS system user icons have:


Then, you should be able to select another image after your image is selected.

Categories
Mac admin'ing

Upping the logging level in Munki

As noted in the Troubleshooting section of the Munki wiki, you can increase the logging level for Munki clients.

The default logging level is 1, which looks like this:
Dec 12 2019 20:04:20 -0800 GoogleChrome version 79.0.3945.79 (or newer) is already installed.

If you increase the logging level to 4, it will look like this:
Dec 12 2019 20:08:23 -0800 DEBUG1: Found GoogleChrome, version 79.0.3945.79 in catalog testing
Dec 12 2019 20:08:23 -0800 DEBUG1: Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Dec 12 2019 20:08:23 -0800 DEBUG1: Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Dec 12 2019 20:08:23 -0800 DEBUG1: Using version_comparison_key CFBundleShortVersionString
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item has version 79.0.3945.79
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item is the same.
Dec 12 2019 20:08:23 -0800 DEBUG1: Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Dec 12 2019 20:08:23 -0800 DEBUG1: Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Dec 12 2019 20:08:23 -0800 DEBUG1: Using version_comparison_key CFBundleShortVersionString
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item has version 79.0.3945.79
Dec 12 2019 20:08:23 -0800 DEBUG1: Installed item is the same.

which looks very similar to the output from a manual sudo managedsoftwareupdate -vvv run:

Found GoogleChrome, version 79.0.3945.79 in catalog testing
Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Using version_comparison_key CFBundleShortVersionString
Installed item has version 79.0.3945.79
Installed item is the same.
Found Info.plist at /Applications/Google Chrome.app/Contents/Info.plist
Checking /Applications/Google Chrome.app/Contents/Info.plist for CFBundleShortVersionString 79.0.3945.79...
Using version_comparison_key CFBundleShortVersionString
Installed item has version 79.0.3945.79
Installed item is the same.

So if you want to see the equivalent of managedsoftwareupdate -vvv in the /Library/Managed Installs/Logs/ManagedSoftwareUpdate.log, I’d recommend using LoggingLevel 4.