Categories
Mac admin'ing

How to check the Carbon Black version installed

In Carbon Black 6.3.0 and 7.0.1, it isn’t super obvious how to check for the version installed.

For example, if you run defaults read /Applications/VMware\ Carbon\ Black\ EDR.app/Contents/Info.plist, you’ll see CFBundleInfoDictionaryVersion = "6.0"; (yes, even if you have version 7 installed), and you’ll also see CFBundleShortVersionString = "1.0"; and CFBundleVersion = 1;. Not terribly helpful.

Apparently, though, there is a hidden plist inside of the binary file, so if you run plutil -p /Applications/VMware\ Carbon\ Black\ EDR.app/Contents/MacOS/CbOsxSensorService | grep "CFBundleShortVersionString", you’ll then see for 7.0.1, for example, "CFBundleShortVersionString" => "7.0.1.16317"

FYI: It doesn’t seem you can get that same info using the plistlib Python library, because the binary isn’t a binary plist, it’s a giant binary file that happens to have plist info inside of it.

Categories
Mac admin'ing

Scripting changing user icons: dsimport prompts for password in zsh

Apple is moving toward making zsh the default shell instead of bash, and it may even eventually remove bash completely from being preinstalled on macOS.

So lots of Mac admins are working to revise scripts from bash to zsh.

Last year, I blogged about Scripting changing the user picture in macOS and referenced this script in particular, which works wonders… that is, unless you try to switch it to zsh.

If you run it as is (using bash), it changes the user picture just fine:

dscl . delete /Users/username JPEGPhoto
dscl . delete /Users/username Picture
userpic.sh username /Library/User\ Pictures/Animals/Zebra.tif

Successfully imported users picture.

If you switch it to zsh, though, it gets permission is denied and then prompts for the password of the user whose picture you’re trying to change:

dscl . delete /Users/username JPEGPhoto
dscl . delete /Users/username Picture
userpic.sh username /Library/User\ Pictures/Animals/Zebra.tif

/usr/local/bin/userpic.sh:16: permission denied: /Library/Caches/username.picture.dsimport
username's password:

So for now, unless someone comments below “Oh, you just need to change this line to get it to work in zsh,” I would hold off on switching that script over to zsh.

Categories
Mac admin'ing

Using installinstallmacos.py to get beta installers

Usually, if you use installinstallmacos.py, you’ll get the already-released installers:

# ProductID Version Build Post Date Title
1 001-15219 10.15.5 19F2200 2020-06-15 macOS Catalina
2 001-04366 10.15.4 19E2269 2020-05-04 macOS Catalina
3 061-86291 10.15.3 19D2064 2020-03-23 macOS Catalina
4 041-91758 10.13.6 17G66 2019-10-19 macOS High Sierra
5 001-57224 10.15.7 19H4 2020-10-27 macOS Catalina
6 061-26589 10.14.6 18G103 2019-10-14 macOS Mojave
7 001-51042 10.15.7 19H2 2020-09-24 macOS Catalina
8 001-36735 10.15.6 19G2006 2020-08-06 macOS Catalina
9 041-88800 10.14.4 18E2034 2019-10-23 macOS Mojave
10 041-90855 10.13.5 17F66a 2019-10-23 Install macOS High Sierra Beta
11 061-26578 10.14.5 18F2059 2019-10-14 macOS Mojave
12 001-36801 10.15.6 19G2021 2020-08-12 macOS Catalina

If you’re in the Apple Beta Software Program (technically, you don’t have to be, but you may want to be to make sure you’re in compliance with Apple terms of use), you can run

sudo installinstallmacos.py --seedprogram CustomerSeed --ignore-cache

And that should get you full installers for beta releases as well:

# ProductID Version Build Post Date Title
1 061-77704 10.15.4 19E242d 2020-02-26 macOS Catalina Beta
2 001-15219 10.15.5 19F2200 2020-06-15 macOS Catalina
3 001-06847 10.15.6 19G60d 2020-06-30 macOS Catalina Beta
4 001-58883 11.0.1 20B5012d 2020-10-29 macOS Big Sur Beta
5 001-04366 10.15.4 19E2269 2020-05-04 macOS Catalina
6 001-36801 10.15.6 19G2021 2020-08-12 macOS Catalina
7 061-86291 10.15.3 19D2064 2020-03-23 macOS Catalina
8 041-91758 10.13.6 17G66 2019-10-19 macOS High Sierra
9 001-57224 10.15.7 19H4 2020-10-27 macOS Catalina
10 061-26589 10.14.6 18G103 2019-10-14 macOS Mojave
11 001-51042 10.15.7 19H2 2020-09-24 macOS Catalina
12 001-36735 10.15.6 19G2006 2020-08-06 macOS Catalina
13 041-88800 10.14.4 18E2034 2019-10-23 macOS Mojave
14 041-90855 10.13.5 17F66a 2019-10-23 Install macOS High Sierra Beta
15 061-26578 10.14.5 18F2059 2019-10-14 macOS Mojave
16 061-44345 10.15.2 19C39d 2019-11-15 macOS Catalina Beta

Categories
Mac admin'ing

Updates to the AutoPkgReviewAndRun.py script

3.5 years ago, I created a script to automate running AutoPkg recipes while also verifying trust info and prompting the user to approve or deny any changes.

With some prompting from some folks on the #autopkg channel of the MacAdmins Slack, I made a few changes to the script:

  • You can now run the script but have it only verify trust info without running the recipes in the recipe list (--verifyonly)
  • Conversely, you can have it only run the recipes in the recipe list without verifying them first (--runonly)
  • If you want, you can also specify a recipe list using either the --recipe-list or -l flag

More details in this pull request.

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

Allowing Outset-run scripts to have access to user folders

Because of TCC/PPPC, which Apple introduced in macOS 10.14, scripts and applications have to ask for permissions to do certain things, especially things like reading user home directory files.

If you have an Outset login script that tries to access something in the home directory, you may find in the ~/Library/Logs/outset.log that you get a Failure processing [name of script, command that failed] Operation not permitted error.

I tried creating a PPPC profile for the script itself. That didn’t work. I tried creating a PPPC profile for /usr/local/outset/outset. That didn’t work. I tried creating a PPPC profile for /bin/zsh. That didn’t work. I tried creating a PPPC profile that allowed all three to have access to all files. That didn’t work.

So, finally, I ran a tccutil reset All to reset the database, and then I logged in again, and it asked for Python to have access to the home folder the script was trying to read.

So I created a PPPC profile to allow Python (the one Outset is using) to have access to the home folder the script was trying to read, and the script ran just fine.

I’m not an expert on this, and any follow-up questions you have would probably be best directed to the #outset channel on the MacAdmins Slack (I’m over there too) instead of in the comments of this post (blog comments aren’t a great venue for tech support), but I thought sharing one case that worked might be helpful for others running into the same issue.

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

Terminal command to tell if a macOS directory is SIP-protected

Starting with El Capitan (OS X 10.11), Apple started using System Integrity Protection (SIP) in macOS, so that certain directories would be not writable, even by root. Here’s a quick reference for a couple of commands you can use to see if a directory or file is SIP-protected, as that may change from macOS version to macOS version.

Method 1

ls -lO (that’s a lowercase L, followed by a capital o, not the number 0), and look for restricted.

Example: ls -lO /Library/Updates/
total 2224
-rw-r--r--@ 1 root wheel restricted 181 Jul 29 10:22 PPDVersions.plist
-rw-r--r--@ 1 root wheel restricted 1130219 Jul 29 10:22 ProductMetadata.plist
-rw-r--r-- 1 root wheel restricted 260 Jul 29 10:17 index.plist

Method 2

xattr -l (that’s a lowercase L) and then the name of the directory. Look for com.apple.rootless

Example: xattr -l /Library/Updates/
com.apple.rootless: SoftwareUpdate

Special thanks to @revolize and @Magneto on the MacAdmins Slack!

Categories
Mac admin'ing

Scripting SSH off/on without needing a PPPC/TCC profile

You used to be able to use /usr/sbin/systemsetup -f -setremotelogin off or /usr/sbin/systemsetup -f -setremotelogin on to script disabling or enabling SSH on macOS.

Now that macOS has Privacy Preferences Policy Control, which needs a profile delivered by a user-approved MDM, you may get this error: setremotelogin: Turning Remote Login on or off requires Full Disk Access privileges., which can be especially annoying if the script’s parent process isn’t code-signed (and thus can’t be used in a PPPC profile), as /usr/sbin/period isn’t, for example. (Read more at Use the systemsetup command-line utility on macOS Catalina 10.15.)

For now, a workaround for this is to simply load or unload the launch daemon that enables/disables SSH: /bin/launchctl load -w /System/Library/LaunchDaemons/ssh.plist or /bin/launchctl unload -w /System/Library/LaunchDaemons/ssh.plist

P.S. Since these are things you’re scripting via something like Munki or Jamf, I’m assuming you’re testing the commands as root.

Categories
Mac admin'ing

Running daily, weekly, and monthly scripts in macOS using periodic

Background

I was looking for time-based project similar to Outset (which runs boot and login scripts stored in various directories), and apparently there’s one already baked into macOS that will run daily, weekly, and monthly scripts.

Shoutout to @elios on the MacAdmins Slack for letting me know about periodic

Launch Daemons

If you run sudo launchctl list | grep periodic-, you’ll see that these launch daemons are running:

com.apple.periodic-monthly
com.apple.periodic-weekly
com.apple.periodic-daily

And, though I don’t love SIP in general, it’s great for this, because you can’t actually disable the launch daemons:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.periodic-daily.plist
/System/Library/LaunchDaemons/com.apple.periodic-daily.plist: Operation not permitted while System Integrity Protection is engaged

So that means as long as you can enforce your daily, weekly, and monthly scripts being in the right place, with the right permissions, and with the right hash, they’ll be run regularly-ish.

Locations of Scripts

You can find scripts in /etc/periodic/daily, /etc/periodic/weekly, and /etc/periodic/monthly. You can also put your own scripts in there (root-owned, 755 permissions), and they’ll run alongside the ones that come with macOS.

According to /etc/defaults/periodic.conf, though, there’s another recommended place to put scripts:

# periodic script dirs
local_periodic="/usr/local/etc/periodic"

So that would be /usr/local/etc/periodic/daily, /usr/local/etc/periodic/weekly, and /usr/local/etc/periodic/monthly. Having your scripts separated from the built-in scripts may be a good idea, even though they’ll run fine alongside the built-in scripts.

Logging

If your script has any echo commands, the output will go to the appropriate log file (by default, those logs would be /var/log/daily.out, /var/log/weekly.out, and /var/log/monthly.out), but there won’t necessarily (again, with the default settings) be any other indicators in the daily, weekly, and monthly logs that your scripts ran.

The format of the log seems to be a date/time, all the echo statements from the scripts run, and then a closer like -- End of daily/weekly/monthly output --.

Invoking manually

If you don’t want to wait until the next day, week, or month, you can do some manual testing by running a command like this, for example: sudo periodic daily

No TCC/PPPC support

Allowing full disk access to a script relies on giving that access to the actual parent process. As far as I can tell, the parent process is the /usr/sbin/periodic binary, but that binary (although shipped with macOS) isn’t code-signed.