Disabling Recent Tags in the Finder window sidebar

rtrouton, 29/11/2021 | Source: Der Flounder

Every so often, something gets added to macOS and enabled by default where I wish it was off by default. The Tags section of the Finder’s sidebar is one of those additions.

Screen Shot 2021 11 29 at 10 04 13 AM

Fortunately for my preferences, I recently figured out (thanks to Bob Gendler’s method for discovering settings via the unified logs) that display of the Tags section was controlled via the following setting:

Domain: com.apple.finder
Key: ShowRecentTags
Value: Boolean

To show Recent Tags in the Finder’s sidebar, run the following command as the logged-in user:

defaults write com.apple.Finder ShowRecentTags -bool true

Screen Shot 2021 11 29 at 10 41 26 AM

Here’s how the Recent Tags setting should now appear in the Finder preferences:

Screen Shot 2021 11 29 at 10 03 48 AM

 

To remove Recent Tags from the Finder’s sidebar, run the following command as the logged-in user:

defaults write com.apple.Finder ShowRecentTags -bool false

Screen Shot 2021 11 29 at 10 40 53 AM

 

Here’s how the Recent Tags setting should now appear in the Finder preferences:

Screen Shot 2021 11 29 at 10 06 54 AM

 

The new setting will not apply until the Finder is restarted, which can be accomplished via either logging out and logging back in or running the following command as the logged-in user:

killall Finder

Screen Shot 2021 11 29 at 10 06 16 AM

 

After the Finder restart, the Tags section should no longer appear in the Finder window sidebar:

Screen Shot 2021 11 29 at 10 06 24 AM

 

In my case, I wanted them off permanently so I’ve also written a profile which can enforce this. It’s available via the link below:

https://github.com/rtrouton/profiles/blob/main/DisableRecentTagsinFinderSidebar

Session videos from Jamf Nation User Conference 2021 now available

rtrouton, 19/11/2021 | Source: Der Flounder

Jamf has posted the session videos for from Jamf Nation User Conference 2021, including the video for my AutoPkg In The Cloud session.

For those interested, all of the the JNUC 2021 session videos are available on YouTube. For convenience, I’ve linked my session here.

Running Jamf Pro actions from outside Jamf Pro

rtrouton, 01/11/2021 | Source: Der Flounder

Every so often, I need to have Jamf Pro perform actions where it’s difficult to arrange the timing and task order I want using the options available from the Jamf Pro server’s end. An example of this would be following an OS upgrade. I want the following:

  • Update the computer inventory record in Jamf Pro as soon as possible that the OS upgrade has occurred.
  • Don’t interfere with any other processes that Jamf Pro may be running at that time.

To address this, I want to use the following workflow:

  1. Make sure the Jamf Pro agent hasn’t run anything for at least the last five minutes.
  2. Enforce the Jamf Pro agent’s management framework
  3. Send the Jamf Pro server an updated inventory.

To run these tasks, I’m using a self-destructing LaunchDaemon and script. For more details, please see below the jump.

I’ve written an example script, which does the following:

  • Creates a LaunchDaemon
  • Creates a script in /var/root which is triggered to run by the LaunchDaemon

Once triggered to run, the script stored in /var/root verifies that the Mac can communicate with the Jamf Pro server. Once communication is verified, it takes the following actions:

  • Checks to see if the /var/log/jamf.log file has been modified in the previous five minutes.
  • Once it has been verified that the /var/log/jamf.log file has not been modified for at least the last five minutes, the script runs the following functions:
  1. Runs jamf manage to enforce the management framework using the latest available data from the Jamf Pro server
  2. Runs jamf recon to send an updated inventory to the Jamf Pro server
  3. Deletes LaunchDaemon file
  4. Deletes script file
  5. Unloads LaunchDaemon

Note: The order for deletion and unloading is important. If the LaunchDaemon is unloaded before the script deletes the LaunchDaemon’s and script’s file, LaunchD will stop the script’s run at the point where the LaunchDaemon unload command occurred. Both the script and LaunchDaemon are in the computer’s memory, so it’s possible to delete the files before the script unloads the LaunchDaemon from LaunchD.

This script is available below and also from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/jamf_pro_manage_inventory_update_and_check_in


#!/bin/bash
# Script for use with Jamf Pro when you want to trigger an update of the management framework, followed by an inventory update.
#
# The LaunchDaemon and accompanying script created by running this script verifies that the Mac can communicate with the Jamf Pro server.
# Once communication is verified, it takes the following actions:
#
# Checks to see if the /var/log/jamf.log file has been modified in the previous five minutes.
#
# Once it has been verified that the /var/log/jamf.log file has not been modified for at least the last five minutes,
# the script runs the following functions:
#
# Runs jamf manage to enforce the management framework using the latest available data from the Jamf Pro server
# Runs jamf recon to send an updated inventory to the Jamf Pro server
# Deletes LaunchDaemon file
# Deletes script file
# Unloads LaunchDaemon
#
#
# Note: The "runjamfproinventoryupdate.sh" script which is part of this script has the following variable set:
#
# jamfpro_server_port="443"
#
# This port is correct for all Jamf Cloud-hosted installations of Jamf Pro.
#
# If your Jamf Pro server is not using port 443, please change this port to the correct number.
# For on-premise Jamf Pro installations, this port is most commonly port 8443. If your Jamf Pro
# server is using port 8443, the variable should look like this:
#
# jamfpro_server_port="8443"
#
# If any previous instances of the runjamfproinventoryupdate LaunchDaemon and script exist,
# unload the LaunchDaemon and remove the LaunchDaemon and script files
if [[ -n $(/bin/launchctl list | grep "com.github.runjamfproinventoryupdate") ]]; then
/bin/launchctl bootout system/com.github.runjamfproinventoryupdate
fi
# Delete LaunchDaemon and script files files if they exist
/bin/rm -f \
"/Library/LaunchDaemons/com.github.runjamfproinventoryupdate.plist" \
"/var/root/runjamfproinventoryupdate.sh"
# Create the runjamfproinventoryupdate LaunchDaemon by using cat input redirection
# to write the XML contained below to a new file.
#
# The LaunchDaemon will run at load and every minute thereafter.
temp_directory=$(mktemp -d)
/bin/cat > "$temp_directory/com.github.runjamfproinventoryupdate.plist" << 'JAMF_PRO_INVENTORY_UPDATE_LAUNCHDAEMON'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.github.runjamfproinventoryupdate</string>
<key>ProgramArguments</key>
<array>
<string>sh</string>
<string>/var/root/runjamfproinventoryupdate.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>60</integer>
</dict>
</plist>
JAMF_PRO_INVENTORY_UPDATE_LAUNCHDAEMON
# Create the runjamfproinventoryupdate script by using cat input redirection
# to write the shell script contained below to a new file.
/bin/cat > "$temp_directory/runjamfproinventoryupdate.sh" << 'JAMF_PRO_INVENTORY_UPDATE_SCRIPT'
#!/bin/bash
jamfpro_server_address=$(/usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url)
jamfpro_server_address="${jamfpro_server_address#*//}"
jamfpro_server_address="${jamfpro_server_address%%/}"
jamfpro_server_port="443"
jamf_binary="/usr/local/jamf/bin/jamf"
CheckSiteNetwork (){
# CheckSiteNetwork function adapted from Facebook's check_corp function script.
# check_corp script available on Facebook's IT-CPE Github repo:
#
# check_corp:
# This script verifies a system is on the corporate network.
# Input: CORP_URL= set this to a hostname on your corp network
# Optional ($1) contains a parameter that is used for testing.
# Output: Returns a check_corp variable that will return "True" if on
# corp network, "False" otherwise.
# If a parameter is passed ($1), the check_corp variable will return it
# This is useful for testing scripts where you want to force check_corp
# to be either "True" or "False"
# USAGE:
# check_corp # No parameter passed
# check_corp "True" # Parameter of "True" is passed and returned
site_network="False"
ping=$(host -W .5 $jamfpro_server_address)
# If the ping fails – site_network="False"
[[ $? -eq 0 ]] && site_network="True"
# Check if we are using a test
[[ -n "$1" ]] && site_network="$1"
}
CheckTomcat (){
# Verifies that the JSS's Tomcat service is responding.
tomcat_chk=$(nc -z -w 5 $jamfpro_server_address $jamfpro_server_port > /dev/null; echo $?)
if [ "$tomcat_chk" -eq 0 ]; then
/usr/bin/logger "Machine can connect to $jamfpro_server_address. Proceeding."
else
/usr/bin/logger "Machine cannot connect to $jamfpro_server_address. Exiting."
exit 0
fi
}
CheckLogAge (){
# Verifies that the /var/log/jamf.log hasn't been written to for at least five minutes.
# This should help ensure that both an inventory update and check-in can run and not
# have to wait for a policy to finish running.
jamf_log="/var/log/jamf.log"
current_time=$(date +%s)
last_modified=$(stat -f %m "$jamf_log")
if [[ $(($current_time-$last_modified)) -gt 300 ]]; then
/usr/bin/logger "Log has not been modified in the past five minutes. Proceeding."
else
/usr/bin/logger "Log has been modified in the past five minutes. Exiting."
exit 0
fi
}
UpdateManagementAndInventory (){
# Verifies that the Mac can communicate with the Jamf Pro server.
# Once communication is verified, it takes the following actions:
#
# 1. Runs jamf manage to enforce the Jamf Pro management framework
# 2. Runs jamf recon to send an updated inventory to the Jamf Pro server
#
jss_comm_chk=$($jamf_binary checkJSSConnection > /dev/null; echo $?)
if [[ "$jss_comm_chk" -gt 0 ]]; then
/usr/bin/logger "Machine cannot connect to the JSS. Exiting."
exit 0
elif [[ "$jss_comm_chk" -eq 0 ]]; then
/usr/bin/logger "Machine can connect to the JSS. Updating management framework and updating inventory."
$jamf_binary manage
$jamf_binary recon
fi
}
SelfDestruct (){
# Removes script and associated LaunchDaemon
if [[ -f "/Library/LaunchDaemons/com.github.runjamfproinventoryupdate.plist" ]]; then
/bin/rm "/Library/LaunchDaemons/com.github.runjamfproinventoryupdate.plist"
fi
rm -rf $0
if [[ -n $(/bin/launchctl list | grep "com.github.runjamfproinventoryupdate") ]]; then
/bin/launchctl bootout system/com.github.runjamfproinventoryupdate
fi
}
CheckSiteNetwork
if [[ "$site_network" == "False" ]]; then
/usr/bin/logger "Unable to verify access to site network. Exiting."
fi
if [[ "$site_network" == "True" ]]; then
/usr/bin/logger "Access to site network verified"
CheckTomcat
CheckLogAge
UpdateManagementAndInventory
SelfDestruct
fi
exit 0
JAMF_PRO_INVENTORY_UPDATE_SCRIPT
# Once the LaunchDaemon file has been created, fix the permissions
# so that the file is owned by root:wheel and set to not be executable
# After the permissions have been updated, move the LaunchDaemon into
# place in /Library/LaunchDaemons.
/usr/sbin/chown root:wheel "${temp_directory}/com.github.runjamfproinventoryupdate.plist"
/bin/chmod 644 "${temp_directory}/com.github.runjamfproinventoryupdate.plist"
/bin/chmod a-x "${temp_directory}/com.github.runjamfproinventoryupdate.plist"
/bin/mv "${temp_directory}/com.github.runjamfproinventoryupdate.plist" "/Library/LaunchDaemons/com.github.runjamfproinventoryupdate.plist"
# Once the script file has been created, fix the permissions
# so that the file is owned by root:wheel and set to be executable
# After the permissions have been updated, move the script into the
# place that it will be executed from.
/usr/sbin/chown root:wheel "$temp_directory/runjamfproinventoryupdate.sh"
/bin/chmod 755 "$temp_directory/runjamfproinventoryupdate.sh"
/bin/chmod a+x "$temp_directory/runjamfproinventoryupdate.sh"
/bin/mv "$temp_directory/runjamfproinventoryupdate.sh" "/var/root/runjamfproinventoryupdate.sh"
# After the LaunchDaemon and script are in place with proper permissions,
# load the LaunchDaemon to begin the script's execution.
if [[ -f "/Library/LaunchDaemons/com.github.runjamfproinventoryupdate.plist" ]] && [[ -x "/var/root/runjamfproinventoryupdate.sh" ]]; then
/bin/launchctl bootstrap system "/Library/LaunchDaemons/com.github.runjamfproinventoryupdate.plist"
fi
# Remove temp directory
/bin/rm -rf "$temp_directory"
exit 0

view raw

jamf_pro_manage_inventory_update_and_check_in.sh

hosted with ❤ by GitHub

This technique is pretty flexible and can be used to trigger other tasks with Jamf Pro. One example would be triggering installation of a particular software package faster than usual. In this scenario, you may have a particular software installation which is a module for X software, but only members of a specific LDAP group are supposed to get that module. So the module is set for installation on check-in and scoped as follows:

  • Target: Macs with X software installed.
  • Limitation: LDAP group
  • Exclusion: Macs with Module Installed.

Your check-in is scheduled to happen every fifteen minutes, but you get feedback from management that this process can’t wait fifteen minutes. It needs to happen within five minutes or sooner. No problem; this technique can be adapted to do the following:

  1. Runs jamf recon to send an updated inventory to the Jamf Pro server (to make sure that the module installation policy has the Mac in scope.)
  2. Runs jamf policy to trigger installation of the module.
  3. Deletes LaunchDaemon file
  4. Deletes script file
  5. Unloads LaunchDaemon

After that, add the script to your X Software install policy and set it to run as an After script. The module should now install within five minutes if installing X software was the last action taken by Jamf Pro.

An example script is available below:


#!/bin/bash
# Script for use with Jamf Pro when you want to trigger an inventory update followed by a policy check-in.
#
# The LaunchDaemon and accompanying script created by running this script verifies that the Mac can communicate with the Jamf Pro server.
# Once communication is verified, it takes the following actions:
#
# Checks to see if the /var/log/jamf.log file has been modified in the previous five minutes.
#
# Once it has been verified that the /var/log/jamf.log file has not been modified for at least the last five minutes,
# the script runs the following functions:
#
# Runs jamf recon to to send an updated inventory to the Jamf Pro server
# Runs jamf policy to force a check-in and run whatever policies are available to run on check-in.
# Deletes LaunchDaemon file
# Deletes script file
# Unloads LaunchDaemon
#
# Note: The "runjamfprocheckin.sh" script which is part of this script has the following variable set:
#
# jamfpro_server_port="443"
#
# This port is correct for all Jamf Cloud-hosted installations of Jamf Pro.
#
# If your Jamf Pro server is not using port 443, please change this port to the correct number.
# For on-premise Jamf Pro installations, this port is most commonly port 8443. If your Jamf Pro
# server is using port 8443, the variable should look like this:
#
# jamfpro_server_port="8443"
#
# If any previous instances of the runjamfprocheckin LaunchDaemon and script exist,
# unload the LaunchDaemon and remove the LaunchDaemon and script files
if [[ -n $(/bin/launchctl list | grep "com.github.runjamfprocheckin") ]]; then
/bin/launchctl bootout system/com.github.runjamfprocheckin
fi
# Delete LaunchDaemon and script files files if they exist
/bin/rm -f \
"/Library/LaunchDaemons/com.github.runjamfprocheckin.plist" \
"/var/root/runjamfprocheckin.sh"
# Create the runjamfprocheckin LaunchDaemon by using cat input redirection
# to write the XML contained below to a new file.
#
# The LaunchDaemon will run at load and every minute thereafter.
temp_directory=$(mktemp -d)
/bin/cat > "$temp_directory/com.github.runjamfprocheckin.plist" << 'JAMF_PRO_CHECKIN_LAUNCHDAEMON'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.github.runjamfprocheckin</string>
<key>ProgramArguments</key>
<array>
<string>sh</string>
<string>/var/root/runjamfprocheckin.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>60</integer>
</dict>
</plist>
JAMF_PRO_CHECKIN_LAUNCHDAEMON
# Create the runjamfprocheckin script by using cat input redirection
# to write the shell script contained below to a new file.
/bin/cat > "$temp_directory/runjamfprocheckin.sh" << 'JAMF_PRO_CHECKIN_SCRIPT'
#!/bin/bash
jamfpro_server_address=$(/usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url)
jamfpro_server_address="${jamfpro_server_address#*//}"
jamfpro_server_address="${jamfpro_server_address%%/}"
jamfpro_server_port="443"
jamf_binary="/usr/local/jamf/bin/jamf"
CheckSiteNetwork (){
# CheckSiteNetwork function adapted from Facebook's check_corp function script.
# check_corp script available on Facebook's IT-CPE Github repo:
#
# check_corp:
# This script verifies a system is on the corporate network.
# Input: CORP_URL= set this to a hostname on your corp network
# Optional ($1) contains a parameter that is used for testing.
# Output: Returns a check_corp variable that will return "True" if on
# corp network, "False" otherwise.
# If a parameter is passed ($1), the check_corp variable will return it
# This is useful for testing scripts where you want to force check_corp
# to be either "True" or "False"
# USAGE:
# check_corp # No parameter passed
# check_corp "True" # Parameter of "True" is passed and returned
site_network="False"
ping=$(host -W .5 $jamfpro_server_address)
# If the ping fails – site_network="False"
[[ $? -eq 0 ]] && site_network="True"
# Check if we are using a test
[[ -n "$1" ]] && site_network="$1"
}
CheckTomcat (){
# Verifies that the JSS's Tomcat service is responding.
tomcat_chk=$(nc -z -w 5 $jamfpro_server_address $jamfpro_server_port > /dev/null; echo $?)
if [ "$tomcat_chk" -eq 0 ]; then
/usr/bin/logger "Machine can connect to $jamfpro_server_address. Proceeding."
else
/usr/bin/logger "Machine cannot connect to $jamfpro_server_address. Exiting."
exit 0
fi
}
CheckLogAge (){
# Verifies that the /var/log/jamf.log hasn't been written to for at least five minutes.
# This should help ensure that both an inventory update and check-in can run and not
# have to wait for a policy to finish running.
jamf_log="/var/log/jamf.log"
current_time=$(date +%s)
last_modified=$(stat -f %m "$jamf_log")
if [[ $(($current_time-$last_modified)) -gt 300 ]]; then
/usr/bin/logger "Log has not been modified in the past five minutes. Proceeding."
else
/usr/bin/logger "Log has been modified in the past five minutes. Exiting."
exit 0
fi
}
UpdateInventoryAndRunCheckin (){
# Verifies that the Mac can communicate with the Jamf Pro server.
# Once communication is verified, it takes the following actions:
#
# 1. Runs jamf recon to send an updated inventory to the Jamf Pro server
# 2. Runs jamf policy to run any policies which run on check-in
#
jss_comm_chk=$($jamf_binary checkJSSConnection > /dev/null; echo $?)
if [[ "$jss_comm_chk" -gt 0 ]]; then
/usr/bin/logger "Machine cannot connect to the JSS. Exiting."
exit 0
elif [[ "$jss_comm_chk" -eq 0 ]]; then
/usr/bin/logger "Machine can connect to the JSS. Updating inventory and doing policy check-in."
$jamf_binary recon
$jamf_binary policy
fi
}
SelfDestruct (){
# Removes script and associated LaunchDaemon
if [[ -f "/Library/LaunchDaemons/com.github.runjamfprocheckin.plist" ]]; then
/bin/rm "/Library/LaunchDaemons/com.github.runjamfprocheckin.plist"
fi
rm -rf $0
if [[ -n $(/bin/launchctl list | grep "com.github.runjamfprocheckin") ]]; then
/bin/launchctl bootout system/com.github.runjamfprocheckin
fi
}
CheckSiteNetwork
if [[ "$site_network" == "False" ]]; then
/usr/bin/logger "Unable to verify access to site network. Exiting."
fi
if [[ "$site_network" == "True" ]]; then
/usr/bin/logger "Access to site network verified"
CheckTomcat
CheckLogAge
UpdateInventoryAndRunCheckin
SelfDestruct
fi
exit 0
JAMF_PRO_CHECKIN_SCRIPT
# Once the LaunchDaemon file has been created, fix the permissions
# so that the file is owned by root:wheel and set to not be executable
# After the permissions have been updated, move the LaunchDaemon into
# place in /Library/LaunchDaemons.
/usr/sbin/chown root:wheel "${temp_directory}/com.github.runjamfprocheckin.plist"
/bin/chmod 644 "${temp_directory}/com.github.runjamfprocheckin.plist"
/bin/chmod a-x "${temp_directory}/com.github.runjamfprocheckin.plist"
/bin/mv "${temp_directory}/com.github.runjamfprocheckin.plist" "/Library/LaunchDaemons/com.github.runjamfprocheckin.plist"
# Once the script file has been created, fix the permissions
# so that the file is owned by root:wheel and set to be executable
# After the permissions have been updated, move the script into the
# place that it will be executed from.
/usr/sbin/chown root:wheel "$temp_directory/runjamfprocheckin.sh"
/bin/chmod 755 "$temp_directory/runjamfprocheckin.sh"
/bin/chmod a+x "$temp_directory/runjamfprocheckin.sh"
/bin/mv "$temp_directory/runjamfprocheckin.sh" "/var/root/runjamfprocheckin.sh"
# After the LaunchDaemon and script are in place with proper permissions,
# load the LaunchDaemon to begin the script's execution.
if [[ -f "/Library/LaunchDaemons/com.github.runjamfprocheckin.plist" ]] && [[ -x "/var/root/runjamfprocheckin.sh" ]]; then
/bin/launchctl bootstrap system "/Library/LaunchDaemons/com.github.runjamfprocheckin.plist"
fi
# Remove temp directory
/bin/rm -rf "$temp_directory"
exit 0

view raw

jamf_pro_inventory_update_and_check_in.sh

hosted with ❤ by GitHub

Use of FileVault Institutional Recovery Keys no longer recommended by Apple

rtrouton, 29/10/2021 | Source: Der Flounder

When legacy FileVault was first introduced as part of Mac OS X 10.3 Panther in 2005, it supported a recovery key method which used a special keychain named FileVaultMaster.keychain which by default had a private key and public key inside. This recovery key was used to provide certificate-based authentication to unlock the encrypted disk images which were used by legacy FileVault.

When FileVault 2 was announced as part of Mac OS X Lion in 2011, Apple announced that there would be two kinds of recovery keys available:

  1. Personal recovery keys (PRK) – These are recovery keys that are automatically generated at the time of encryption. These keys are generated as an alphanumeric string and are unique to the machine being encrypted. In the event that an encrypted Mac is decrypted and then re-encrypted, the existing personal recovery key would be invalidated and a new personal recovery key would be created as part of the encryption process.
  2. Institutional recovery keys (IRK) – These are pre-made recovery keys that can be installed on a system prior to encryption and most often used by a company, school or institution to have one common recovery key that can unlock their managed encrypted systems.

IRKs were the sole part of Apple’s FileVault 1 (also known as legacy FileVault) that was carried over into FileVault 2. IRKs were legacy FileVault’s recovery keys and they were used in almost exactly the same way. The main difference was that they were now used to unlock an encrypted disk as opposed to legacy FileVault’s disk images.

In FileVault 1 deployments, you were asked to set a Master Password when turning on FileVault 1’s encryption. When you set the Master Password, the FileVault 1 encryption process set the password that was entered as the password on the /Library/Keychains/FileVaultMaster.keychain file. In turn, the FileVaultMaster.keychain file contained two keys used for PKI certificate-based authentication (one public key and one private key). When the public and private keys are both stored in one keychain, the keychain can be used to unlock your FileVault 1-encrypted home folder in the event that the password to open it was lost or forgotten. The Master Password only unlocked the keychain and allowed the system to access those two PKI keys. This is the reason why you needed to set the Master Password before encrypting and why it was also important to use the same FileVaultMaster.keychain file across the machines where you wanted to make sure that the same recovery key was being used.

If you were deploying the same recovery key for your FileVault-encrypted Macs, Apple consistently recommended that you go into the FileVaultMaster.keychain file, remove the PKI private key, put the private key somewhere secure and deploy the FileVaultMaster.keychain file with only the public key inside. The reason was that, in the event that the password to the FileVaultMaster.keychain file was compromised, all the compromiser got was one half of the keypair (the public key half.) The private key would not be on the machine and thus not available to compromise the FileVault 1-encrypted homes on the machine. However, FileVault 1 would work with both the public and private keys stored in /Library/Keychains/FileVaultMaster.keychain.

In FileVault 2, Apple changed removing the private key from being a suggested best practice to being a technical requirement. If you want to use an institutional recovery key, your FileVaultMaster.keychain file needs to have just the public key in it. If both public and private keys are stored in the /Library/Keychains/FileVaultMaster.keychain file on a Mac, FileVault 2 will ignore the keychain and not use it as an institutional recovery key. In this case, enabling FileVault 2 encryption will automatically generate a personal recovery key.

That was then, this is now

Over the years, the PRK gained functionality while the IRK largely did not. With the advent of PRK escrow systems (found in most present-day MDM solutions), the IRK’s main advantage of being a recovery key which could be mass-deployed came to seen instead as a weakness. After all, better to have recovery keys where each encrypted drive has its own unique key in place of the danger of a compromised recovery key being able to unlock all the machines in your Mac environment.

You can also only use an IRK to unlock or decrypt if you were booted to macOS Recovery. Recovery’s limited functionality meant that users of an IRK would have to do some preparation work, including making sure that the IRK’s keychain file was available somewhere which could be reached from Recovery.

Meanwhile, Apple has made changes to the environments where you could use an IRK. Beginning with macOS Catalina, macOS Recovery now prompted you to log in with either a password associated with an admin user or with a PRK.

Screen Shot 2020 04 06 at 4 48 45 PM

Screen Shot 2020 04 06 at 1 53 51 PM

You could not use an IRK at this login screen. So now Mac admins found themselves in the situation where they had an IRK, but couldn’t use it to authenticate in Recovery and get to the point where they could use the IRK.

With the introduction of Apple Silicon Macs, Apple has also discontinued Target Disk Mode functionality. This also affected the use of IRKs because it removes the ability to unlock using an IRK while the locked drive is connected to another Mac via Target Disk Mode.

The combination of all of these factors has led to Apple making a written recommendation to not use IRKs for institutional deployments of FileVault on Macs.

Screen Shot 2021 10 29 at 3 24 29 PM

It’s been a long run for IRKs and they still do work as recovery keys (for now), but in my opinion it’s time to follow Apple’s stated recommendation and stop the deployment and use of IRKs as FileVault recovery keys.

Silently uninstalling system extensions on macOS Monterey and earlier

rtrouton, 26/10/2021 | Source: Der Flounder

As part of the move from using kernel extensions to system extensions, there is an issue which can be a problem for Mac admins: Uninstalling a system extension from the command line usually involves a GUI window popping up and requesting admin authorization.

Screen Shot 2021 10 26 at 8 25 37 AM

This can be a problem for admins because it requires the logged-in user to:

  • Have admin rights.
  • Understand what the dialog is telling them.
  • Be willing to enter admin credentials when prompted.

For macOS Monterey, this issue has been addressed by the addition of the RemovableSystemExtensions property to the com.apple.system-extension-policy profile payload. This is used to identify system extensions which can be deactivated without requiring admin authorization.

Screen Shot 2021 10 26 at 11 41 26 AM

However, the RemovableSystemExtensions property is new in macOS Monterey and does not apply to macOS Big Sur and earlier. In the past, Mac admins have dealt with this issue through user education, providing warnings like the one shown below, or (in macOS 11.3 and later) removing the profile which authorized the system extension. In the latter case, removing authorization will also unload the system extension.

Screen Shot 2021 10 26 at 8 24 59 AM

However, there is a way to bypass the admin authorization. For more details, please see below the jump.

There are two parts to being able to silently uninstall a system extension. The first is that the app developer must have written into their code signed app a way to trigger Apple’s uninstall API for system extensions. An example of this can be found in the code of the open source Santa tool created by Google:

https://github.com/google/santa/blob/d2b6c2b6c2de33ba2267c54f9affcbf592046050/Source/santa/main.m#L64-L78

For Santa, this functionality can be triggered from the command line by running the following command:

/Applications/Santa.app/Contents/MacOS/santa --unload-system-extension

This call to Apple’s uninstall API must be from the same code-signed app which is using the system extension. Other applications or functions trying to call the uninstall function from outside the app will not be authorized to uninstall the system extension.

Assuming that the code is included in the app to trigger Apple’s uninstall API for system extensions, the next step is found in the authorization database as the setting which controls whether or not the logged-in user is prompted for admin credentials is located there. Running the following command should show the setting:

security authorizationdb read com.apple.system-extensions.admin

That should display output similar to what’s shown below:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
<key>class</key>
<string>rule</string>
<key>created</key>
<real>600880872.76305306</real>
<key>modified</key>
<real>656531090.20857704</real>
<key>rule</key>
<array>
<string>authenticate-admin-nonshared</string>
</array>
<key>version</key>
<integer>0</integer>
</dict>
</plist>

view raw

com.apple.system-extensions.admin.unmodified.plist

hosted with ❤ by GitHub

The rule key’s value is what determines whether the logged-in user is asked for admin authorization:


<key>rule</key>
<array>
<string>authenticate-admin-nonshared</string>
</array>

view raw

gistfile1.txt

hosted with ❤ by GitHub

By default, this value is set to the following:

authenticate-admin-nonshared

https://gist.github.com/rtrouton/bb4e4136af5ee1b8160f1638b68f1a86

However, this value can be changed. Setting it to the value shown below will stop the request for admin authorization:

allow

https://gist.github.com/rtrouton/dd26f434ff28edaac455b6b396b26e44

To change com.apple.system-extensions.admin‘s rule key value to allow, you can use the commands shown below:


security authorizationdb read com.apple.system-extensions.admin > /tmp/com.apple.system-extensions.admin.plist
/usr/libexec/PlistBuddy -c "Set rule:0 allow" /tmp/com.apple.system-extensions.admin.plist
security authorizationdb write com.apple.system-extensions.admin < /tmp/com.apple.system-extensions.admin.plist

view raw

gistfile1.txt

hosted with ❤ by GitHub

To revert back to the default value of authenticate-admin-nonshared, you can use the commands shown below:


security authorizationdb read com.apple.system-extensions.admin > /tmp/com.apple.system-extensions.admin.plist
/usr/libexec/PlistBuddy -c "Set rule:0 authenticate-admin-nonshared" /tmp/com.apple.system-extensions.admin.plist
security authorizationdb write com.apple.system-extensions.admin < /tmp/com.apple.system-extensions.admin.plist

view raw

gistfile1.txt

hosted with ❤ by GitHub

An example of how this can be used is with Microsoft Defender, which may deploy multiple system extensions. The example script below will uninstall Microsoft Defender and includes deactivating the system extensions without prompting the logged-in user for admin credentials:


#!/bin/bash
# Uninstall Microsoft Defender
# unload the launchd plist for the current user
currentUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
# Temp plist files used for import and export from authorization database.
management_db_original_setting="$(mktemp).plist"
management_db_edited_setting="$(mktemp).plist"
management_db_check_setting="$(mktemp).plist"
# Expected settings from management database for com.apple.system-extensions.admin
original_setting="authenticate-admin-nonshared"
updated_setting="allow"
ManagementDatabaseUpdatePreparation() {
# Create temp plist files
touch "$management_db_original_setting"
touch "$management_db_edited_setting"
touch "$management_db_check_setting"
# Create backup of the original com.apple.system-extensions.admin settings from the management database
/usr/bin/security authorizationdb read com.apple.system-extensions.admin > "$management_db_original_setting"
# Create copy of the original com.apple.system-extensions.admin settings from the management database for editing.
/usr/bin/security authorizationdb read com.apple.system-extensions.admin > "$management_db_edited_setting"
}
UpdateManagementDatabase() {
if [[ -r "$management_db_edited_setting" ]] && [[ $(/usr/libexec/PlistBuddy -c "Print rule:0" "$management_db_edited_setting") = "$original_setting" ]]; then
/usr/libexec/PlistBuddy -c "Set rule:0 $updated_setting" "$management_db_edited_setting"
if [[ $(/usr/libexec/PlistBuddy -c "Print rule:0" "$management_db_edited_setting" ) = "$updated_setting" ]]; then
echo "Edited $management_db_edited_setting is set to allow system extensions to be uninstalled without password prompt."
echo "Now importing setting into authorization database."
/usr/bin/security authorizationdb write com.apple.system-extensions.admin < "$management_db_edited_setting"
if [[ $? -eq 0 ]]; then
echo "Updated setting successfully imported."
UpdatedAuthorizationSettingInstalled=1
fi
else
echo "Failed to update $management_db_edited_setting file with the correct setting to allow system extension uninstallation without prompting for admin credentials."
fi
fi
}
RestoreManagementDatabase() {
/usr/bin/security authorizationdb read com.apple.system-extensions.admin > "$management_db_check_setting"
if [[ ! $(/usr/libexec/PlistBuddy -c "Print rule:0" "$management_db_check_setting") = "$original_setting" ]]; then
if [[ -r "$management_db_original_setting" ]] && [[ $(/usr/libexec/PlistBuddy -c "Print rule:0" "$management_db_original_setting") = "$original_setting" ]]; then
echo "Restoring original settings to allow system extension uninstallation only after prompting for admin credentials."
echo "Now importing setting into authorization database."
/usr/bin/security authorizationdb write com.apple.system-extensions.admin < "$management_db_original_setting"
if [[ $? -eq 0 ]]; then
echo "Original setting successfully imported."
OriginalAuthorizationSettingInstalled=1
fi
else
echo "Failed to update the authorization database with the correct setting to allow system extension uninstallation only after prompting for admin credentials."
fi
fi
}
if [[ -n "$currentUser" && "$currentUser" != "root" ]]; then
/bin/launchctl bootout gui/$(/usr/bin/id -u "$currentUser") /Library/LaunchAgents/com.microsoft.wdav.tray.plist
fi
# Unload the launchd plist for the daemon
/bin/launchctl bootout system /Library/LaunchDaemons/com.microsoft.fresno.plist
/bin/launchctl bootout system /Library/LaunchDaemons/com.microsoft.fresno.uninstall.plist
# unload the kernel extension
/sbin/kextunload -v 6 -b com.microsoft.wdavkext
# Check for loaded system extensions.
wdavExtensions=$(/usr/bin/systemextensionsctl list | /usr/bin/grep -Eo "com.microsoft.wdav.[^[:space:]]+" | /usr/bin/uniq)
if [[ -n "$wdavExtensions" ]]; then
# Prepare to update authorization database to allow system extensions to be uninstalled without password prompt.
ManagementDatabaseUpdatePreparation
# Update authorization database with new settings.
UpdateManagementDatabase
# Uninstall the system extensions
#
# Note: If the updated settings to allow system extensions to be uninstalled without password prompt were not
# added successfully, this will prompt the user to enter their admin credentials, so a message will be displayed
# to let the user know.
if [[ -z UpdatedAuthorizationSettingInstalled ]]; then
/usr/bin/osascript -e 'display dialog "As part of the uninstall process for Microsoft" & "\nDefender, please enter your admin password when prompted." & "\n" & "\nYou may be prompted up to three times."buttons {"Understood"} default button 1 with icon Caution'
fi
# The system extensions will now be uninstalled. If needed, a message will be displayed to warn the user
# to enter their admin credentials.
#
# After the message is displayed, the user will be prompted for the password to authorize removal of Defender's system extensions.
for anExtension in ${wdavExtensions}; do
"/Applications/Microsoft Defender ATP.app/Contents/MacOS/wdavdaemon" uninstall-system-extension "$anExtension"
done
# Once the system extensions are uninstalled, the relevant settings for the authorization database will be restored from backup to their prior state.
if [[ -n UpdatedAuthorizationSettingInstalled ]]; then
RestoreManagementDatabase
if [[ -n "$OriginalAuthorizationSettingInstalled" ]]; then
echo "com.apple.system-extensions.admin settings in the authorization database successfully restored to $original_setting."
rm -rf "$management_db_original_setting"
rm -rf "$management_db_edited_setting"
rm -rf "$management_db_check_setting"
fi
fi
fi
# kill Microsoft Defender
/usr/bin/killall -SIGKILL "Microsoft Defender" "Microsoft Defender ATP"
# remove the global stuff
/bin/rm -rf "/Applications/Microsoft Defender ATP.app" \
/Library/Logs/Microsoft/mdatp \
"/Library/Application Support/Microsoft/Defender" \
"/Library/Application Support/Microsoft Defender ATP" \
/var/log/fresno*.log \
/Library/Extensions/com.microsoft.wdavkext \
/Library/Extensions/wdavkext.kext \
/Library/LaunchDaemons/com.microsoft.fresno.* \
/Library/LaunchAgents/com.microsoft.wdav.tray.plist
# remove stuff in users folders
localUsers=$(/usr/bin/dscl . -list /Users | /usr/bin/grep -v "^_")
for userName in ${localUsers}; do
# get path to user's home directory
userHome=$(/usr/bin/dscl . -read "/Users/$userName" NFSHomeDirectory 2>/dev/null | /usr/bin/sed 's/^[^\/]*//g')
if [[ -d "$userHome" && "$userHome" != "/var/empty" ]]; then
/bin/rm -rf "$userHome/Library/Saved Application State/com.microsoft.wdav.savedState" \
"$userHome/Library/Preferences/com.microsoft.wdav.plist" \
"$userHome/Library/Preferences/com.microsoft.wdavtray.plist" \
"$userHome/Library/Caches/Microsoft/uls/com.microsoft.wdav"
fi
done
# remove the mdatp user and group
/usr/bin/dscl /Local/Default -delete /Users/_mdatp
/usr/bin/dscl /Local/Default -delete /Groups/_mdatp
# forget the packages
allPKGS=$(/usr/sbin/pkgutil –pkgs="com.microsoft.wdav")
for aPKG in ${allPKGS}; do
/usr/sbin/pkgutil –forget "$aPKG"
done
exit 0

view raw

Microsoft_Defender_Uninstall.sh

hosted with ❤ by GitHub

Before Microsoft Defender uninstallation:


username@computername ~ % systemextensionsctl list
2 extension(s)
— com.apple.system_extension.network_extension
enabled active teamID bundleID (version) name [state]
* * UBF8T346G9 com.microsoft.wdav.netext (101.47.27/101.47.27) Microsoft Defender ATP Network Extension [activated enabled]
— com.apple.system_extension.endpoint_security
enabled active teamID bundleID (version) name [state]
* * UBF8T346G9 com.microsoft.wdav.epsext (101.47.27/101.47.27) Microsoft Defender ATP Endpoint Security Extension [activated enabled]
username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

After Microsoft Defender uninstallation:


username@computername ~ % systemextensionsctl list
2 extension(s)
— com.apple.system_extension.network_extension
enabled active teamID bundleID (version) name [state]
UBF8T346G9 com.microsoft.wdav.netext (101.47.27/101.47.27) Microsoft Defender ATP Network Extension [terminated waiting to uninstall on reboot]
— com.apple.system_extension.endpoint_security
enabled active teamID bundleID (version) name [state]
UBF8T346G9 com.microsoft.wdav.epsext (101.47.27/101.47.27) Microsoft Defender ATP Endpoint Security Extension [terminated waiting to uninstall on reboot]
username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

Disabling the Erase All Contents and Settings function on macOS Monterey

rtrouton, 25/10/2021 | Source: Der Flounder

As part of macOS Monterey, Apple has introduced the Erase All Contents and Settings function to macOS for Apple Silicon Macs. In my Monterey testing, this setting was very useful because it enabled me to reset my Mac to a factory default condition without having to spend extra time wiping the drive and installing a fresh copy of macOS.

Screen Shot 2021 10 14 at 9 46 35 AM

However, having this functionality available may not desired in all environments. For Mac admins supporting these environments, Apple has provided a new profile management option, as part of the Restrictions payload, which disables the Erase All Contents and Settings functionality on Apple Silicon Macs.

Screen Shot 2021 10 14 at 10 14 39 AM

For more details, please see below the jump.

I’ve written a profile to disable Erase All Contents and Settings functionality which does the following:

1. Removes the Erase All Contents and Settings… menu option from the System Preferences option.

Screen Shot 2021 10 14 at 9 47 17 AM

2. Blocks the Erase Assistant app from running.

Note: When the profile is installed, the Erase Assistant app will show the following message:

Erase Assistant is not supported on this Mac.

Screen Shot 2021 10 14 at 9 56 16 AM

In order to apply this profile, there are some pre-requisites:

  • User Approved Mobile Device Management (UAMDM) must be enabled on the target Mac.
  • Profile must be installed by an MDM server.

Those pre-requisites also apply to deploying this profile, which is available via the link below:

https://github.com/rtrouton/profiles/tree/main/DisableEraseAllContentsAndSettings

When deployed, the profile should appear similar to this in System Preference’s Profiles preference pane.

Screen Shot 2021 10 14 at 9 49 29 AM

Slides from the “AutoPkg in the Cloud” session at Jamf Nation User Conference 2021

rtrouton, 21/10/2021 | Source: Der Flounder

For those who wanted a copy of my cloud hosted-AutoPkg talk at at the Jamf Nation User Conference 2021 conference, here are links to the slides in PDF and Keynote format.

Using AutoPkg to create an installer package for SAP GUI

rtrouton, 15/10/2021 | Source: Der Flounder

I’ve previously posted guides on how to manually package SAP GUI:

However it’s also possible to automate creating a SAP GUI installer package using AutoPkg. To do this, you’ll need the following:

  1. AutoPkg
  2. The SAP GUI recipes from the rtrouton-recipes repo
  3. The latest SAP GUI installer application’s disk image
  4. A SAP GUI templates.jar file (optional)

For more details, please see below the jump.

The AutoPkg recipes I’ve written will need the following information provided:

  • SAP GUI’s numeric information
  • SAP GUI’s alphanumeric information
  • SAP GUI’s application bundle identifier information

None of this information is available from the installer application, so you’ll need to provide it to AutoPkg using a com.sapgui.identifier.plist file which will be included along with the latest SAP GUI installer application’s disk image. Please see below for how to gather this information.

Preparing SAP GUI for AutoPkg

1. Copy the latest SAP GUI installer application’s disk image to a test Mac or virtual machine.

2. Mount the disk image and launch the SAP GUI for Java Installer installer application on the test Mac or virtual machine.

Screen Shot 2021 07 22 at 2 16 27 PM

3. Follow the prompts to install.

Screen Shot 2021 07 22 at 2 16 55 PM

Screen Shot 2021 07 22 at 2 17 20 PM

Screen Shot 2021 07 22 at 2 17 32 PM

Screen Shot 2021 07 22 at 2 17 56 PM

4. Once installed, run the following command to get SAP GUI’s alphanumeric version.

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" NSHumanReadableCopyright | awk '{print $2$3$4}'

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" NSHumanReadableCopyright| awk '{print $2$3$4}'

Screen Shot 2021 07 22 at 2 34 18 PM

5. Once you have the alphanumeric version, run the following command to get SAP GUI’s numeric version.

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" CFBundleShortVersionString

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" CFBundleShortVersionString

Screen Shot 2021 07 22 at 2 35 47 PM

6. Once you have both versions, run the following command to get SAP GUI’s bundle identifier:

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" CFBundleIdentifier

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" CFBundleIdentifier

Screen Shot 2021 07 22 at 2 45 12 PM

7. Open Terminal and run the following command to create a com.sapgui.identifier.plist file with the alphanumeric version information for SAP GUI:

defaults write /path/to/com.sapgui.identifier AlphanumericVersionString version_info_goes_here

For example, if the SAP GUI alphanumeric version is 7.70rev2, run the following command to create a com.sapgui.identifier.plist file on the Desktop:

defaults write $HOME/Desktop/com.sapgui.identifier AlphanumericVersionString 7.70rev2

Screen Shot 2021 07 22 at 2 49 14 PM

8. Run the following command to add the numeric version information for SAP GUI to the com.sapgui.identifier.plist file:

defaults write /path/to/com.sapgui.identifier CFBundleShortVersionString version_info_goes_here

For example, if the SAP GUI numeric version is 770.4.200, run the following command

defaults write $HOME/Desktop/com.sapgui.identifier CFBundleShortVersionString 770.4.200

Screen Shot 2021 07 22 at 2 59 28 PM

9. Run the following command to add the bundle identifier information for SAP GUI to the com.sapgui.identifier.plist file:

defaults write /path/to/com.sapgui.identifier CFBundleIdentifier bundle_identifier_info_goes_here

For example, if the SAP GUI bundle identifier is com.sap.platin, run the following command

defaults write $HOME/Desktop/com.sapgui.identifier CFBundleIdentifier com.sap.platin

Screen Shot 2021 07 22 at 2 58 32 PM

10. Once the com.sapgui.identifier.plist file is created and populated with the version and bundle identifier information, copy it to a convenient location along with the latest SAP GUI installer application’s disk image.

11. If you’re planning to include a templates.jar file with the SAP GUI installer, copy the templates.jar file to the same location.

Screen Shot 2021 06 18 at 12 12 51 PM

12. Create a .zip file of the following files:

  • corp.sap.sapgui.identifier.plist
  • Latest SAP GUI installer application’s disk image
  • templates.jar (if applicable)

For this example, I’m going to use the following filename for the .zip file:

latestsapgui.zip

This .zip file will be what’s used by AutoPkg to create the SAP GUI installer package.

Screen Shot 2019 10 09 at 11 30 35 AM

 

Using the AutoPkg recipes

To accomodate the fact that some folks will have a templates.jar file which they want to include and some folks won’t, I’ve written two sets of .pkg recipes:

  • SAPGUIWithTemplate.pkg – Use when you’re using a templates.jar file
  • SAPGUIWithoutTemplate.pkg – Use when you’re not using a templates.jar file

Both sets of recipes share a common SAPGUI.download recipe.

SAP GUI does not have a publicly accessible download link, so there are two options available for adding the .zip file you created earlier to your AutoPkg workflow:

1. Posting the .zip file to a web server for download.

You can upload the .zip file to a web server or other online storage location which AutoPkg can download files from. This is my preferred method because you can set the download URL in an AutoPkg override. Once that’s done, you just need to replace the .zip file on the web server when a new version of SAP GUI comes out. The next time it’s run, AutoPkg will download the new .zip file and handle the rest automatically.

2. Using AutoPkg’s -p option.

AutoPkg includes an -p option for specifying a file for input, in place of downloading from a URL.

Screen shot 2015 01 26 at 7 36 26 am

For example, if you wanted to run the SAPGUIWithTemplate.pkg recipe and use a .zip file stored locally on your Mac, you would use the following command to run an AutoPkg override of the SAPGUIWithTemplate.pkg recipe and specify a .zip file named latestsapgui.zip:

autopkg run local.pkg.SAPGUIWithTemplate -p /path/to/latestsapgui.zip

Once you’ve sorted out how you’re adding the .zip file you created to your AutoPkg workflow, you should be able to use these recipes to create SAP GUI installer packages for use in your own environment.

For those who want to use code signing to sign the SAP GUI installers created by AutoPkg, I’ve also created the following .sign recipes:

SAPGUIWithTemplate.sign – Use when you’re using a templates.jar file
SAPGUIWithoutTemplate.sign – Use when you’re not using a templates.jar file

Each .sign recipe uses the appropriate .pkg recipe as a parent recipe.

Installer package identifiers and the mystery of the missing Java 11 files

rtrouton, 11/10/2021 | Source: Der Flounder

As part of developing new AutoPkg recipes to support SapMachine‘s new Long Term Support (LTS) distribution for Java 17, I ran into a curious problem when testing. When I ran the SapMachine Java 17 LTS installer that was being generated by AutoPkg, I was seeing the following behavior:

  • SapMachine Java 17 LTS is installed by itself – no problem
  • SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed – no problem
  • SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed – SapMachine Java 11 LTS is removed, only SapMachine Java 17 LTS is installed now.

I double-checked the preinstall script for the SapMachine Java 17 LTS installer. It is supposed to remove an existing SapMachine Java 17 LTS installation with the same version info, but it should not have also been removing SapMachine Java 11 LTS. After a re-review of the script and additional testing, I was able to rule out the script as the problem. But what was causing this behavior? Also, why was it happening in this order?

  • SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed

But not this order?

  • SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed

The answer was in how the package’s package identifier was set up. For more details, please see below the jump.

When I was writing the AutoPkg .pkg recipes for SapMachine Java 17 LTS, I used the existing SapMachine Java 11 LTS .pkg recipe as a template. Included with that recipe was the following:


<key>id</key>
<string>net.java.openjdk.sapmachine</string>

view raw

gistfile1.txt

hosted with ❤ by GitHub

For AutoPkg’s PkgCreator processor, this defines the package identifier.

I didn’t change that. That was a mistake, because that meant that Apple’s Installer was going to see SapMachine Java 17 LTS as an upgrade install for an existing SapMachine Java 11 LTS installation. Why is this important?

When macOS’s Installer does an upgrade install, it does the following:

  1. Consults its store of existing installer package receipts.
  2. Identifies if it has a receipt by a previous installer with a matching package identifier. If multiple receipts are found, the latest installed is used.
  3. Uses the Bill of Materials (BOM) stored with the receipt to generate a list of files which are in the receipt’s BOM and are not part of the new installer’s BOM.
  4. Removes the files in question.
  5. Adds the files from the current installer.

Note: Files added, removed or changed outside of the main installation process will not be included in the BOM. Since these files are not included in the BOM’s listing, the installer process will not move, change or delete these files. Examples of files not included or tracked by the BOM would be files added or moved by an installer package’s preinstall or postinstall scripts.

From Installer‘s point of view, the two packages were identified this way:

SapMachine Java 11 LTS

  • Identifier: net.java.openjdk.sapmachine
  • Version: 11.xx.xx

SapMachine Java 17 LTS

  • Identifier: net.java.openjdk.sapmachine
  • Version: 17.xx.xx

That meant that, on a Mac where SapMachine Java 11 LTS had been installed previously using an installer package with the net.java.openjdk.sapmachine package identifier, Installer interpreted the SapMachine Java 17 LTS install as being an upgrade for SapMachine Java 11 LTS.

In those conditions, Installer performs the following actions:

  1. Consults the existing installer package receipts.
  2. Identifies the latest version of the SapMachine Java 11 LTS receipt with a matching net.java.openjdk.sapmachine package identifier.
  3. Generates a list of the files installed by the SapMachine Java 11 LTS installer package, using the SapMachine Java 11 LTS receipt’s BOM, and identified those files which were not included in the SapMachine Java 17 LTS installer package’s BOM.
  4. Removes those files.
  5. Adds the files from the SapMachine Java 17 LTS installer.

The effect is that SapMachine Java 11 LTS’s files were automatically removed when SapMachine Java 11 LTS is installed first and then SapMachine Java 17 LTS is subsequently installed.

The fix? Make sure the SapMachine Java 17 LTS installer package has a different package identifier.

As I was using AutoPkg to build the installer package in question, I could include variables as part of the package identifier to help ensure the package identifier would be unique for each version of the SapMachine Java 17 LTS installer package.


<key>id</key>
<string>net.java.openjdk.sapmachine.universal.%version%.%BUILD_NUMBER%</string>

view raw

gistfile1.txt

hosted with ❤ by GitHub

For example, for SapMachine Java 17.35 LTS, the package identifier looks like this in the AutoPkg-created installer package:


<key>id</key>
<string>net.java.openjdk.sapmachine.universal.17.35</string>

view raw

gistfile1.txt

hosted with ❤ by GitHub

Slides and video from the “AutoPkg in the Cloud” session at MacSysAdmin 2021

rtrouton, 05/10/2021 | Source: Der Flounder

For those who wanted a copy of my cloud hosting for AutoPkg talk at at the MacSysAdmin 2021 conference, here are links to the slides in PDF and Keynote format.

The video of my session is available for download from here: