Starting with macOS Catalina, Apple’s default shell for the Terminal changed from bash to zsh. As part of that change, the behavior of the history command changed.

Bash:

Running the history command lists all history entries.

Zsh:

Running the history command lists only the 15 most recent history entries.

To see more history entries, you can pass a numerical value to the history command. However, the bash and zsh shells handle this differently also.

Bash:

history (number_goes_here): Shows the most recent entries as defined by the number.

For example, the command shown below will show the fifteen most recent entries:

history 15

Zsh:

history (number_goes_here): Shows all entries which follow number_goes_here.

For example, the following command will show all history entries after history entry #1 (which will include all history entries):

history 1

history -(number_goes_here): Shows the most recent entries as defined by the number.

For example, the command shown below will show the fifteen most recent entries:

history -15

For those interested in why this behavior is different, I recommend reading the zshbuiltins manpage’s section on the fc command. This can be accessed by running the following command:

man zshbuiltins

The reason is that in the zsh shell, the history command’s mechanism is using the following built-in function:

fc

For my own needs, I wanted to recreate bash‘s default behavior for the history command in the zsh shell. The way I chose to do this was to add the following line to the .zshrc file in my home folder.

The .zshrc file is the configuration file for the zsh shell and is used to customize the zsh shell’s behavior. Adding this line to the .zshrc file will run the following command whenever the history command is invoked:

history 1

The downside to this approach is that it interferes with the original functionality of the history command. An alternative approach would be to add the following line to the .zshrc file:

Now all history entries will be displayed when the following command is entered:

fullhistory

As part of working on a new AutoPkg download recipe today, I very quickly got stuck on a problem. The app in question is Poly’s Lens software and its download page uses JavaScript to provide the download URL for the latest version of the Lens software. While this may have benefits for the vendor, this means I can’t scrape the page for the download URL’s address using AutoPkg.

Discussing the issue in the #autopkg channel of the MacAdmins Slack, folks started poking around the Lens app and discovered that it was using the Squirrel framework to provide software update functionality to the app. Assuming that meant that the app would phone home for updates, ahousseini was kind enough to monitor the app’s HTTP and HTTPS traffic using CharlesProxy. Shortly thereafter, he reported seeing Lens send the following API request using curl:

This HTTPS traffic was Lens sending an API request to see if it was running the latest version of the software. The relevant parts from our perspective were the items shown below:

This told us what format we should expect API output to be (in this case, JSON):

This told us the query which was being sent to the API endpoint:

This told us the API endpoint:

Putting this information together, the following curl command gets a response from the API endpoint:

The API response looks similar to this:

Part of the API response’s output includes the download URL for the latest version:

Now that we have this information, how to use it with AutoPkg? For more details, please see below the jump:

You can use AutoPkg’s URLTextSearcher processor for this purpose. The URLTextSearcher processor is designed to use curl to download information from a URL and then perform a regular expression match on the returned information. Because the processor is using curl, one of the processor’s options is to include curl options using the curl_opts input option, to include those options when performing the download request using curl.

The processor also includes a request_headers input option, which allows headers to be included with the download request.

Between being able to send headers and configure curl options, this meant that I had everything needed to query the API. The last part was being able to parse the API endpoint’s response to get the URL which was needed. For that, the re_pattern input option allowed a Python regular expression to parse the output for what was needed.

In an AutoPkg .download recipe, configuring the URLTextSearcher processor like this works to run the desired API call:

When AutoPkg runs the recipe in verbose mode, you should be able to see the URLTextSearcher processor do the following:

1. Run the API call
2. Parse the output
3. Use the designated regular expression to return the desired download URL as output from the processor.

From there, other AutoPkg processors (in this case the URLDownloader processor) can use the output from the URLTextSearcher processor to read the download URL from the output and then use it to download a disk image containing the latest Poly Lens app.

For the full verbose output, please see below:

For reference, I’ve posted AutoPkg recipes for Poly Lens which use the technique I’ve discussed in this post:

https://github.com/autopkg/rtrouton-recipes/tree/master/PolyLens

As part of my preparations for Jamf’s planned authentication changes to the Classic API, I’ve been working more with the JamfUploader AutoPkg processors for Jamf Upload. These processors have emerged as a successor to JSSImporter, the original tool available to upload installer packages and other components to Jamf Pro using AutoPkg.

As part of my work with Jamf Upload, I’ve also updated my autopkg-conductor script to allow the use of either Jamf Upload’s JamfUploaderSlacker AutoPkg processor or JSSImporter’s Slacker AutoPkg processors. For more details, please see below the jump.

JamfUploaderSlacker and Slacker both allow uploading information to a Slack channel using a webhook. The message which appears in Slack should look similar to what is shown below:

JamfUploaderSlacker

Slacker

To accommodate using either the JamfUploaderSlacker or Slacker processor, I’ve added a new slack_autopkg_processor variable to autopkg-conductor. If this variable is set correctly with the values specified in the script, it’ll enable autopkg-conductor to use the correct processor when reporting to a Slack channel.

If the slack_autopkg_processor variable is set, but isn’t one of the two expected values, the use of the processors is bypassed. Instead, all logged output would be sent to Slack if a Slack webhook is set up.

Another change to autopkg-conductor is to error reporting. In the previous version of autopkg-conductor, the error log was sent to Slack even if no errors were detected.

This behavior has been changed. If no errors have been detected, the error log will no longer be sent to Slack. Instead, the information that the error log was empty will be logged to the logs stored on the Mac which is running autopkg-conductor.

The autopkg-conductor script is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/autopkg-conductor

Jamf has enabled a new feature on Jamf Protect tenants, where you can generate a download URL for the latest Jamf Protect client installer and uninstaller. These download URLs do not require authentication, but a security identifier unique to the Jamf Protect tenant needs to be included as part of the download URL:

Once generated, the download links are formatted similar to this:

Installer:

Uninstaller:

For example, if the Jamf Protect tenant and security identifier were as shown below, the curl commands would look like this:

• Jamf Protect tenant: companyname.protect.jamfcloud.com
• Security token: c1f0d1cb-8ddc-4f36-9578-58a7388053d5

Installer:

Uninstaller:

Since the Jamf Protect installer and uninstaller can be downloaded from your Jamf Protect tenant, this means that it’s now possible to use AutoPkg to get the latest Jamf Protect client installer and uninstaller as soon as they are available from your Jamf Protect tenant. For more details, please see below the jump.

To help facilitate this, I’ve written a set of Jamf Protect AutoPkg recipes.

These download URLs are tenant-specific and not public, so you will need to create a recipe override and enter the URL and security identifier Jamf provides into the DOWNLOAD_URL and DOWNLOAD_UUID values of the override.

For example, if the Jamf Protect tenant and security identifier were as shown below, the override would look like this:

• Jamf Protect tenant: companyname.protect.jamfcloud.com
• Security token: c1f0d1cb-8ddc-4f36-9578-58a7388053d5

To follow up on my earlier posts on the Jamf Pro Server Installer for macOS being retired, Jamf has added the following to the Deprecations and Removals section of the Jamf Pro 10.36.0 release notes:

Support Ending for Hosting Jamf Pro Server on macOS—Starting with the release of Jamf Pro 10.37.0, hosting the Jamf Pro server on macOS will no longer be supported. Mac computers with Apple silicon are not supported by the Jamf Pro Installer for macOS. In addition, the Jamf Pro Installer for macOS will not be available to download. The Jamf Pro utilities that were included in the Jamf Pro Installer for macOS—Composer, Jamf Admin, Jamf Recon, and Jamf Remote—will be made available as a separate download.

If you want to migrate your Jamf Pro server from macOS to Jamf Cloud, contact Jamf Support. If you want to keep your server on premise, you can migrate your Jamf Pro server to one of the following servers: Red Hat Enterprise Linux, Ubuntu, or Windows. For more information, see the Migrating to Another Server article.

For those folks who are running on-premise Jamf Pro servers on Macs, I strongly recommend contacting Jamf Support right now and plan a migration if you haven’t already. As of February 21st, 2022, Jamf’s published support for running Jamf Pro includes the following OS, database and Java versions:

As part of a recent task to build an AutoPkg recipe which creates an installer package for a screen saver, I ran into an issue. The vendor, for reasons that no doubt make sense to them, split the version information for the screen saver across two separate keys:

• Major part of the version number: Stored in the CFBundleShortVersionString key of the screen saver’s Info.plist file
• Minor part of the version number: Stored in the CFBundleVersion key of the screen saver’s Info.plist file

What this meant is that for version 1.4 of the screen saver, the version information was stored as follows:

• CFBundleShortVersionString key: 1
• CFBundleVersion key: 4

Getting this information was not the problem. AutoPkg includes a PlistReader processor which allows multiple values to be read from one plist file, so I used it as shown below to read the CFBundleShortVersionString key’s and the CFBundleVersion key’s values and store them in the following variables:

• CFBundleVersion key: minor_version
• CFBundleShortVersionString: major_version

So now I had the version info (in separate pieces) and now I needed to put them together. The problem I was seeing was that my usual solution, AutoPkg’s Versioner processor is set up to read one value from a plist file. I had two values and neither were in a plist file.

Fortunately, there are multiple ways to solve this problem. The first I thought of was to build a new plist as part of the recipe’s run and put the version information in. The workflow works like this:

1. Use the PlistReader processor to read the desired information.
2. Use the FileCreator processor processor to create a new plist file with the version information formatted as needed.
3. Use the PlistReader processor to read the version information out of the newly-created plist file.

This approach works, but now you have a plist file to clean up later. Another approach is to use custom variable assigning as part of another AutoPkg processor’s run. In this case, you’re using an AutoPkg processor and adding a separate argument which is probably unrelated to the other work the processor is doing, but does the value assignment work you couldn’t accomplish otherwise.

A pretty safe processor to use for this is the EndOfCheckPhase processor. The reason is that by itself, the EndOfCheckPhase processor takes no actions. Instead, it’s used as a marker in AutoPkg recipes to tell AutoPkg to stop checking for new information as part of a recipe’s run. However, even though the EndOfCheckPhase processor doesn’t take actions and doesn’t by default include Arguments values, AutoPkg will still process Arguments values if they’re defined for the EndOfCheckPhase processor. That allows custom variables to be set with values that you couldn’t otherwise set and pass them to AutoPkg. The workflow in this case looks like this:

1. Add the EndOfCheckPhase processor to the very end of the recipe.
2. Perform the desired variable assignment as an Arguments value

The reason to add it to the end is to make sure that all of the other tasks the recipe is performing are completed by the time this processor runs.

In this case, I used this method with the the EndOfCheckPhase processor in the screen saver’s .download recipe to assign the version variable to use the values of the major_version and minor_version variables, separated by a period.

The result for the latest version of the screen saver software is that the version variable is assigned the following value:

I’ve posted the recipes which use this technique for setting version information to GitHub. They’re available via the link below:

https://github.com/autopkg/rtrouton-recipes/tree/master/CarouselCloudScreenSaver

Booting a VMware Fusion virtual machine to the macOS Recovery environment can be challenging, as Fusion uses Command-R as a keyboard shortcut for restoring snapshots.

This is the same keyboard shortcut as booting to macOS Recovery for Intel Macs so if you’re not very fast, or you don’t have the virtual machine window selected correctly, you may be looking at an unwanted request to restore a snapshot instead of macOS Recovery.

Fortunately, there’s a workaround for this behavior which will reliably get you into macOS Recovery. For more details, please see below the jump.

This method relies on VMware Fusion being able to boot a virtual machine from a disk image. So your first step is to create a disk image of the macOS installer for the OS version you want.

You can create this disk image using a tool I’ve written:

https://github.com/rtrouton/create_macos_vm_install_dmg

Once you have the disk image built, use the procedure below to connect the disk image to the virtual machine and boot from it.

1. If necessary, add a CD/DVD to your virtual machine.

2. Connect the disk image of the macOS installer to the virtual machine’s CD/DVD drive.

3. Under the Virtual Machine menu, select Power on to Firmware.

4. Once booted to the Boot Manager screen, use the arrow keys on your keyboard to select the CDROM option.

5. Hit the Return key on your keyboard.

The virtual machine should now boot to the macOS installer’s Recovery environment.

Note: This Recovery environment is separate from the Recovery on your virtual machine’s regular boot drive, but as long as the OS versions match between the VM and the disk image, it shouldn’t matter which disk’s Recovery environment that you’re actually in.

Please see below for what the process of booting from the Boot Manager to the macOS installer’s Recovery environment should look like.

One of the changes brought with macOS 12.3 is that the profiles command line tool now includes a rate limiter for some of its functions:

profiles show

profiles validate

In both cases, running these functions may be limited to once every 23 hours.

For those familiar with rate limitation on the server side, where a server may choose to limit how many calls can be received in a set period from a client, this rate limitation is similar but is set and managed entirely on the client side. This means that there is no bypassing the profiles command’s rate limitation in this case for the Mac in question.

One way this may appear is on Macs which are part of the Automated Device Enrollment program, where the Mac can show its enrollment status by running the following command:

In the event that this command errors, the profiles command will block further attempts to display this information for the next 23 hours. In this situation, you may see output like that shown below:

At this time, I don’t know where the information which tracks this 23 hour limitation is stored, but I did confirm that it is stored somewhere in the writable portion of the Mac’s boot drive. Wiping the Mac’s boot drive, via a disk wipe and OS reinstall or via Erase All Contents and Settings, will remove whatever is tracking and enforcing the 23 hour limitation.

Update – 4-22-2022:

It looks like the file which tracks this information is stored in the following location:

/private/var/db/ConfigurationProfiles/Settings/.profilesFetchTimerCheck

This file is protected by SIP. Thanks to zolotkey in the comments!

Also, in the original version of this post, I had made a mistake and conflated the functions of the following commands:

• profiles renew -type enrollment
• profiles show -type enrollment

The profiles renew -type enrollment command can be used to enroll or re-enroll a Mac which is part of the Automated Device Enrollment program with the MDM server that ADE associates the Mac with. To the best of my knowledge, the renew function of the profiles command does not have a client side rate limitation on macOS 12.3. Thanks also to Richard in the comments for catching my mistake and letting me know about it.

Simple Package Creator.app, an Automator application that will allow the selection of a self-contained application and creates an installer package that enables the installation of the application with pre-set permissions into /Applications, has been updated to version 1.5.

The functionality and operations of the app have not changed from Simple Package Creator 1.4. The main change is that Simple Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Simple Package Creator 1.5, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Simple-Package-Creator

Payload-Free Package Creator.app, an Automator application that allows the selection of an existing script and then create a payload-free package that runs the selected script, has been updated to version 2.4.

The functionality and operations of the app have not changed from Payload-Free Package Creator 2.3. The main change is that Payload-Free Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Payload-Free Package Creator 2.4, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator

In working with folks who want to build installer packages to install the Privileges app, I’ve noticed that a number of them have experienced problems with manually building an installer package for Privileges which correctly installs the Privileges app’s helper tool.

The result of an installer which does not install the helper tool correctly is that when a user requests administrator privileges using the Privileges app, the app prompts them to install the helper tool. This requires administrative rights, which sets up a chicken and egg situation where admin privileges are being required to get admin privileges.

Fortunately, there is an automated method for building the installer package which (so far) has worked correctly in each case I’m familiar with. There are AutoPkg recipes available for creating a Privileges installer package and AutoPkg is able to build a correctly working Privileges installer package.

For more details, please see below the jump.

For those not familiar with using AutoPkg, please follow the process below to build a working Privileges installer package:

Note: If you do not want to install AutoPkg on your own Mac, AutoPkg also runs fine in a macOS virtual machine.

1. If Git is not already installed, install Git.

Note: Git must be installed before installing AutoPkg because AutoPkg uses Git for many of AutoPkg’s functions.

Git is included with Xcode or the Xcode Command Line Tools, so installing either Xcode or the Xcode Command Line Tools will also install the necessary Git support.

2. Download the latest AutoPkg installer from https://autopkg.github.io/autopkg

3. Install AutoPkg.

4. Open Terminal and run the following command:

autopkg repo-add rtrouton-recipes

5. Once the repo has been added, run the following command to create an AutoPkg override of the AutoPkg recipe which creates the installer package:

autopkg make-override com.github.rtrouton.pkg.privileges

6. An AutoPkg override file should be created with the following recipe identifier:

local.pkg.Privileges

You can verify this by opening the override file in a text editor and looking for the Identifier key.

7. Once the override file has been created, run the following command to create a Privileges installer package:

autopkg run local.pkg.Privileges

You should then see output similar to this:

The newly-created Privileges installer package should be stored be in ~/Library/AutoPkg/Cache/local.pkg.Privileges.

8. Repeat process as needed for each new version of Privileges.

After a long run, first beginning with Mac OS X Server 1.0 in 1999, Apple has announced the end of macOS Server as of April 21, 2022. The final version is macOS Server 5.12.2, which runs on macOS Monterey.

macOS Server 5.12.2 has shed many of the features once supported by macOS Server. As of 5.12.2, the following two services are supported:

• Profile Manager
• Open Directory

Both services are not currently available outside of macOS Server, so Apple discontinuing macOS Server also means the end of the line for Apple’s Open Directory directory service and Apple’s Profile Manager MDM service.

For current customers who have purchased macOS Server, macOS Server 5.12.2 remains available in the App Store.

Kandji invited me to discuss the topic of whether you should set up users in your work environment with standard user rights or admin user rights. It’s a great topic and was a lot of fun to dig into, so I’m happy to say that they recorded the discussion between me and Steven Vogt. If you’re interested, the discussion is available on YouTube and I’ve linked it below:

As part of the release of Safari 15.5, there seems to be an issue with Safari being able to load embedded content on some websites. One example is the US State Department’s site for reporting a lost or stolen passport:

https://travel.state.gov/content/travel/en/passports/have-passport/lost-stolen.html

This site has embedded content and Safari is very slow to load that site. The behavior seems to be tied to the Hide IP address from trackers setting in Safari’s privacy settings:

With that setting enabled, slow website loading:

With that setting disabled, normal website loading:

HCS Technology Group posted a white paper recently, showing how to deploy Cisco AnyConnect using Jamf Pro. As part of that documentation, HCS described how to create an installer choices XML file and then use it to create a custom Cisco AnyConnect installer package.

It’s possible to replicate this packaging workflow, including generating an installer choices XML file, using AutoPkg. For more details, please see below the jump.

In this example, there are going to be multiple AutoPkg recipes and support files referenced:

• CiscoAnyConnect.download.recipe – Download recipe for the vendor-supplied Cisco AnyConnect disk image with the vendor-supplied installer package stored inside.
• CiscoAnyConnect.pkg.recipe – Package recipe for Cisco AnyConnect, which generates an installer choices XML file and wraps both the installer choices XML file and the vendor-supplied installer package inside a separate installer package generated by AutoPkg
• Example.xml – Sample VPN profile for Cisco AnyConnect’s VPN module
• Cisco AnyConnect package recipe override – This is the AutoPkg recipe override where you’re defining how the installer choices file is configured and other information being supplied to the Cisco AnyConnect installer by the AutoPkg package creation process.

Important information:

A. You absolutely must create an AutoPkg override to work with these recipes. The download location, configuration for the installer choices XML file and other settings are not included in the AutoPkg recipes themselves and must be defined in the override.

B. The example recipes as written include the following assumptions:

• You’re using the Cisco AnyConnect Umbrella module.
• You’re adding the necessary configuration information for the Cisco AnyConnect Umbrella module to the AutoPkg recipe override.
• You may be using the Cisco AnyConnect VPN module.

C. The Cisco AnyConnect disk image does not have a set address for downloading it, so you will need to do one of the following:

• Download the disk image from Cisco and host it yourself somewhere.
• Change the download URL in the AutoPkg recipe override to match wherever you can currently download the Cisco AnyConnect disk image from.

D. To configure the installer choices XML file, you must designate what modules you want to include using ones and zeros in the AutoPkg override. By default, the .pkg recipe is configured to install all modules:

To change this, change one to zero for the modules you don’t want to install. For example, the configuration below will configure the AnyConnect installer to only install the AnyConnect Umbrella module:

E. If you do not want to have the VPN module installed or enabled, you will need to set the CHOICE_VPN and DISABLE_VPN settings in the recipe override. Please see below for an example:

In this example, the CHOICE_VPN setting is set to zero and the DISABLE_VPN setting is set to true.

F. These recipes allow you to hide the Cisco-provided AnyConnect installers, so that your users will not be able to see them in the Finder. (They will still be visible via the Terminal.) Like the installer choices selection, this can be set using ones and zeros in the AutoPkg override.

To hide, set the HIDE_UNINSTALLERS setting to one:

To not hide the uninstallers, set the HIDE_UNINSTALLERS setting to zero:

G. It’s possible to disable the customer feedback functionality through the installer. To set this to be disabled, set the DISABLE_CUSTOMER_EXPERIENCE_FEEDBACK setting to true.

To leave the customer feedback functionality enabled, set the DISABLE_CUSTOMER_EXPERIENCE_FEEDBACK setting to false.

Please see below for the example .download and .pkg recipes, example VPN XML file and example .pkg recipe override:

Download recipe:

Package recipe: