Archive

Archive for the ‘Scripting’ Category

Using directory membership to manage Apple Remote Desktop permissions

August 22, 2018 3 comments

Apple Remote Desktop (ARD) is a screen sharing and remote administration tool that just about every Mac admin uses at some point. Configuring access permissions for it can be done in several ways:

  1. Using System Preferences’ Sharing preference pane to configure the Remote Management settings.
  2. Using the kickstart command line utility to grant permissions to all or specified users
  3. Using the kickstart command line utility to grant permissions to members of specified directories.

The last item may be the least-known method of assigning permissions, but it can be the most powerful because it allows ARD’s management agent to be configured once then use group membership to assign ARD permissions. For more details, please see below the jump.

Read more…

Automating AutoPkg and JSSImporter setup

July 13, 2018 1 comment

As part of building my autopkg-conductor solution for automating AutoPkg runs, I also wanted to automate the setup of AutoPkg and JSSImporter. My colleague Graham Pugh has written a setup script for his environment, which I was able to adapt and extend for my own needs. For more details, please see below the jump.

Read more…

Automating AutoPkg runs with autopkg-conductor

July 6, 2018 2 comments

About two weeks ago, I noticed I had an SSL error cropping up with one of my AutoPkg recipes:

[Errno socket error] EOF occurred in violation of protocol (_ssl.c:590)

When I investigated what it meant, I wound up at this lengthy issue opened for Python’s requests module. In the end, it seemed to boil down to four issues:

  1. I was running AutoPkg on macOS Sierra 10.12.6.
  2. The recipe I was running used a processor which called Python’s urllib2 library.
  3. Python’s urllib2 library was calling the OS’s installed version of OpenSSL to connect to a server using TLSv1.2 .
  4. The version of OpenSSL included with 10.12.6 does not support TLSv1.2 for the urllib2 library.

When I looked into the situation on macOS High Sierra 10.13.5, Apple had addressed the problem by replacing OpenSSL with LibreSSL. Among other improvements, LibreSSL allowed Python’s urllib2 library to be able to connect to servers using TLSv1.2. Problem solved!

Until I ran into another problem.

I had been using AutoPkgr as my way of managing AutoPkg and scheduling AutoPkg runs. However, when I set up AutoPkgr on a 10.13.5 VM and scheduled my AutoPkg nightly run, nothing happened except my CPU spiked to 100% and AutoPkgr locked up with the pinwheel of patience.

OK, maybe it was something with my VM. No problem, set up a new macOS 10.13.5 VM.

Same problem.

Maybe it was because I was trying to run the VM on VMware’s ESXi? Set up a new VM running in VMware Fusion. Same problem.

Maybe AutoPkgr was getting confused by Apple File System? I set up a 10.13.5 VM which used an HFS+ boot volume. Same problem, replicated on both ESXi and Fusion.

No matter what I tried, trying to run recipes using AutoPkgr on macOS 10.13.x resulted in the following:

  • The VM’s CPU spiking to 100%
  • AutoPkgr locking up with the pinwheel of patience
  • My AutoPkg recipes not running

I was able to eliminate AutoPkg itself as being the issue, as running recipes from the command line using AutoPkg worked fine. With that information in mind, I decided to see if I could replicate what I most liked about using AutoPkgr into another form. In the end, my needs boiled down to three:

  1. I wanted to be able to run a list of AutoPkg recipes on a scheduled basis. These recipes would be .jss recipes for uploading to a Jamf Pro server.
  2. I wanted to be able to post information about those AutoPkg recipes to a Slack channel
  3. I wanted all the error messages from an AutoPkg run, but I didn’t care about all the information that came from a successful AutoPkg run.

With that, I decided to draw on some earlier work done by Sean Kaiser, a colleague who had written a script for managing AutoPkg in the pre-AutoPkgr days. For more details, please see below the jump.

Read more…

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

June 16, 2018 7 comments

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

Read more…

Updated Xcode command line tools installer script now available

June 10, 2018 Leave a comment

A while back, I developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher.

Most of the time it works fine. However, starting with macOS Sierra and continuing on with macOS High Sierra, I occasionally ran into an odd problem. Apple would sometimes have both the latest available Xcode Command Line Tools installer and the just-previous version available on Apple’s Software Update feed.

Screen Shot 2018 06 09 at 12 11 06 PM

The original script was written with the assumption that there would only be one qualifying Xcode Command Line Tools install option available at any one time. When more than one is available, the script isn’t able to correctly identify which Xcode Command Line Tools it should be installing. The result is that the script ends without installing anything.

Apple usually removes the previous version from the Software Update feed within a few days, which allows the script to work normally again. But when it happened this time, I decided to update the script to hopefully fix this issue once and for all. For more details, please see below the jump.

Read more…

Using the Jamf Pro API to mass-delete computers and mobile devices

May 19, 2018 Leave a comment

Periodically, it may be necessary to delete a large number of computers or mobile devices from a Jamf Pro server. However, there is currently a problem in Jamf Pro 10 where trying to delete multiple devices can fail. Jamf is aware of the issue and has assigned it a product issue code (PI-004957), but it has not yet been resolved and remains a known issue as of Jamf Pro 10.4.1.

To work around this issue, you can delete computers and mobile devices one at a time. This does not trigger the performance issues seen with PI-004957, but this can get tedious if you have multiple devices to delete. To help with this, I’ve adapted an earlier script written by Randy Saeks to help automate the deletion process by using a list of Jamf IDs and the API to delete the relevant computers or mobile devices one by one. For more details, please see below the jump.

Read more…

Detecting if a logged-in user on a FileVault-encrypted Mac has a Secure Token associated with their account

May 10, 2018 1 comment

A challenge many Mac admins have been dealing with is the introduction of the Secure Token attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume.

In my own shop, we wanted to be able to identify if the primary user of a Mac had a Secure Token associated with their account. The reason we did this was:

  1. We could alert the affected help desk staff.
  2. We could work with our users to rebuild their Macs on an agreed-upon schedule where their data was preserved.
  3. We could hopefully avoid working with our users on an emergency basis where their data could be lost.

To help with this, we developed a detection script. For more details, please see below the jump.

Read more…

%d bloggers like this: