babgond

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

• Building an SAP GUI installer for macOS
• Packaging SAP GUI for macOS with Java 11 support
• Packaging a SAP GUI installer application for macOS

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.

3. Follow the prompts to install.

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}'

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

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

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

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

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

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.

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.

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.

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.

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:

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.

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

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.

• PDF: https://tinyurl.com/MSA2021PDF
• Keynote: https://tinyurl.com/MSA2021Keynote

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

• https://www.macsysadmin.se/video/day1session3.mp4

When connecting via SSH to a remote Mac running macOS Big Sur, Apple’s user-level privacy controls apply. You can access data in the home folder of the account you’re using to connect, but you can’t access or alter protected data in other account’s home folders.

For most use cases, this is fine. However, there may be circumstances when full disk access for SSH connections is desired. To accommodate for this, Apple added an Allow full disk access for remote users checkbox in the Remote Login settings in System Preference’s Sharing preference pane.

This setting can normally only be enabled by the logged-in user sitting at that Mac. However, there is a way to manage this with a configuration profile. For more details, please see below the jump.

I’ve written a profile to manage full disk access for SSH connections which does the following:

• Enables the Allow full disk access for remote users checkbox in the Remote Login settings in System Preference’s Sharing preference pane
• Enables full disk access for /usr/libexec/sshd-keygen-wrapper

The first part is mainly cosmetic. It enables the Allow full disk access for remote users checkbox, but does not actually enable full disk access for SSH. That function is handled by the second part, which are the PPPC settings to allow full disk access for /usr/libexec/sshd-keygen-wrapper.

In order to apply PPPC settings, 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/EnableFullDiskAccessforSSH

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

Hat tip to poundbangbash for providing the correct PPPC settings for SSH full disk access by allowing full disk access to /usr/libexec/sshd-keygen-wrapper.

I recently needed to set up a connection test so that an outside vendor could verify that firewall rules had been set up correctly on both ends and that a connection which originated at a specific IP address on the vendor’s end was able to resolve a DNS address on our end and make a connection.

I remembered that Python has a simple way to set up a web server, so I decided to use this to create a script which creates a connection listener by setting up a web server on the desired port. For more details, please see below the jump.

Pre-requisites:

• Python 3

The script does the following:

• Creates a temporary directory
• Changes location into the temporary directory
• Creates an index.html file inside the temporary directory
• Starts Python 3’s web service using the content inside the temporary directory

Once running, you should be able to run connection tests against the port number defined in the script. In this example, port 8080 is being used.

Note: If you need to use a privileged port number between 0 – 1023, be aware that you will need to run this script with root privileges or by using authbind.

When the address being checked is connected to, you should see results similar to what’s shown below:

Note: In this case, localhost is being used as the address to check:

Curl connection test:

Telnet connection test using curl:

As a web page is also being created by the script, you can also try connecting via a web browser. If successful, you should see a Hello World message as shown below.

The connection test script is available below:

When setting up software for deployment, it’s usually a good idea to first send it out to a small percentage of the Macs in your environment. That way, if there’s a problem that wasn’t caught in testing, the amount of cleanup required is also small. If that initial deployment works, the software can then be sent out to greater percentages of the Mac population until all of them are eventually covered by the deployment.

This can be a pain to track manually though. New Macs come in, older ones are retired and keeping all Macs covered can turn into a significant investment of time. Fortunately, this is a task which can be automated and enable the Macs to assign themselves to deployment groups based on their machine UUID identifier. For more details, please see below the jump.

This method uses a Jamf Pro Extension Attribute, which is designed to calculate and set a numerical identifier for individual Macs based on the Mac’s machine UUID. This numerical identifier in turn is designed to be used to determine deployment groups.

Once identified, the value will be written to a plist file located in /Library/Preferences. By default, this file is named as follows:

/Library/Preferences/com.companyname.deploymentgroup.plist

You can change the companyname part by setting a different value for the organizationName variable in the Extension Attribute.

If the plist file is present in /Library/Preferences, the Extension Attribute will read the correct value from the plist file.

If the plist file is not present in /Library/Preferences, the Extension Attribute will calculate the correct value and store in the plist as the value of the deploymentGroupAssignmentValue key.

By default, this Extension Attribute is designed to assign Macs to seven deployment groups, with the following percentage of Macs assigned to each group.

When all is working correctly, the Extension Attribute will display one of the following values for each Mac:

When not working properly, the Extension Attribute will display the following value:

The Extension Attribute’s values can then be used as Jamf Pro smart group criteria to create smart groups for software deployment.

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

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/set_deployment_group

Recently, I was working on a task where I wanted to set up an automated process to create manual database snapshots for a database hosted in Amazon’s RDS service. Normally this is a straightforward process because you can use the database’s unique identifier when requesting the database snapshot to be created.

However in this case, the database was being created as part of an Elastic Beanstalk configuration. This meant that there was the potential for the database in question to be removed from RDS and a new one set up, which meant a new unique identifier for the database I wanted to create manual database snapshots from.

The Elastic Beanstalk configuration does tag the database, using a Name tag specified in the Elastic Beanstalk configuration, so the answer seemed obvious: Use the tag information to identify the database. That way, even if the database identifier changed (because a new database had been created), the automated process could find the new database on its own and continue to make snapshots.

One hitch: Within the AWS API, RDS lists only the following three API calls to interact with tags.

• AddTagsToResource
• ListTagsForResource
• RemoveTagsFromResource

ListTagsForResource would seem to be the answer, but the hitch there is that you have to have the database’s Amazon Resource Name (ARN) identifier available first and then use that to list the tags associated with the database:

aws rds add-tags-to-resource --resource-name arn:aws:rds:us-east-1:123456789102:db:dev-test-db-instance --tags Key=Name

I was coming at it from the other end – I wanted to use the tag information to find the database. RDS’s API doesn’t support that.

Fortunately, the RDS API is not the only way to read tags from an RDS database. For more details, please see below the jump.

The answer is that outside of RDS, there is also the Resource Groups Tagging API, which is accessible using the resourcegroupstaggingapi command for the AWS CLI tool. Among other things, the resourcegroupstaggingapi command allows you to identify a specified values for a specified key for a specified service.

For example, if you were looking for a RDS-hosted database whose database identifier you didn’t know, but you did know that it is in AWS’s eu-west-1 region and had a Name tag with the value of VIPDatabase, you could run the following query to get that databases’s ARN identifier:

Once you had the ARN identifier, you could then use the following command to get the matching database’s instance identifier. For this example, we’re using arn:aws:rds:eu-west-1:123456789012:db:database_name_here as the ARN identifier:

aws rds --region eu-west-1 describe-db-instances --db-instance-identifier arn:aws:rds:eu-west-1:123456789012:db:database_name_here --query "*[].{DBInstanceIdentifier:DBInstanceIdentifier}"

Assuming you wanted to use this lookup capability in a shell script, the following code should get you started:

In the case of our example, where you’re looking for a database with a Name tag where the Name tag’s value is VIPDatabase, it would look like this:

Every so often, it may be necessary to generate a report from Jamf Pro on which computers are assigned to a particular person. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the computer inventory records and generate a report in .tsv format.

For more details, please see below the jump.

Pre-requisites:

If setting up a specific Jamf Pro user account for this purpose with limited rights, here are the required API privileges for the account on the Jamf Pro server:

Jamf Pro Server Objects

• Computers: Read

Computer inventory records

• In Jamf Pro, the username field must be populated in the User and Location section of the computer inventory record.

For authentication, the script can accept manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

defaults write com.github.jamfpro-info jamfpro_url https://jamf.pro.server.goes.here:port_number_goes_here

To store the account username in the plist file:

defaults write com.github.jamfpro-info jamfpro_user account_username_goes_here

To store the account password in the plist file:

defaults write com.github.jamfpro-info jamfpro_password account_password_goes_here

This script imports a list of usernames from a plaintext file and uses that information to generate a report about the computers assigned to that username.

Usage:

./Generate_Assigned_Mac_Report_From_Jamf_Pro_Usernames.sh usernames.txt

Plaintext file format should look like this:

The script can also accept one username as input, if a plaintext file containing usernames
is not available.

Usage:

./Generate_Assigned_Mac_Report_From_Jamf_Pro_Usernames.sh

Once the username(s) are read from in from the plaintext file or from manual input, the script takes the following actions:

1. Uses the Jamf Pro API to download all information about the matching computer inventory record in XML format.
2. Pulls the following information out of the inventory entry:

• Jamf Pro ID
• Assigned user’s username
• Assigned user’s email
• Manufacturer
• Model
• Serial Number
• Hardware UDID

3. Create a report in tab-separated value (.tsv) format which contains the following information about the deleted Macs

• Jamf Pro ID
• Assigned user’s username
• Assigned user’s email
• Manufacturer
• Model
• Serial Number
• Hardware UDID
• Jamf Pro URL for the computer inventory record

This script will generate a report in .tsv format with information similar to what’s shown below:

One user:

Multiple users:

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/Generate_Assigned_Mac_Report_From_Jamf_Pro_Usernames

A number of folks noticed that certain older applications they use on macOS stopped working as of August 24th, 2021. As of this date, this appears to affect the following applications among others:

• RSA SecurID Software Token 4.2.1
• Citrix Receiver
• Cisco AnyConnect 4.7 and earlier

Note: This list is not complete, it’s just the ones I’m aware of as of August 24, 2021.

Why this is happening goes back to an episode in 2018, where Symantec had to get out of the PKI certificate issuing business because of a number of issues discovered with how Symantec had been issuing certificates.

As part of these issues, Apple issued an advisory that a number of Symantec Certificate Authority (CA) root certificates were to be distrusted by Apple on a timeline which concluded with the full distrust of Symantec CAs on February 25, 2020.

While this primarily affected website operators, Symantec also issued certificates from the affected Symantec CAs which were used to provide code signing for applications. An example of this is RSA SecurID Software Token 4.2.1.

Update 8-26-2021: RSA has released RSA SecurID Software Token 4.2.2 to resolve the issue with RSA SecurID Software Token 4.2.1. For more details, please see the link below:

https://community.rsa.com/t5/securid-access-product/updated-securid-announces-securid-software-token-4-2-2-for-macos/ta-p/640000?emcs_t=S2h8ZW1haWx8Ym9hcmRfc3Vic2NyaXB0aW9ufEtTUTg5SktCWUQxS1JHfDY0MDAwMHxTVUJTQ1JJUFRJT05TfGhL

In the case of SecureID, this app relies on Qt Core for user interface support and ships copies of the QT Core framework along with the SecureID app. SecurID stores this in the following location:

/Library/Frameworks/stauto32.framework

If you take a look at the installer, you can see where the files are supposed to go.

However, the actual file which is causing the issue is buried further down in the following location:

/Library/Frameworks/stauto32.framework/Versions/4/QtCore.cire

This file is important because the QT Core framework is shipped without Apple’s code signing, which is to say that QT is not using an Apple Developer ID signing certificate to sign QT Core. Instead, QT ships a code signing certificate chain and that information is stored in the QtCore.cire file.

One of the certificates in the code signing certificate chain is using VeriSign Class 3 Public Primary Certification Authority – G5 as its root certificate authority (root CA). That root CA is one of the Symantec CAs which is no longer trusted by Apple.

To summarize: the SecureID app has a component which is signed by a not-trusted certificate. This is causing SecureID to not trust that component, which then prevents the app from launching correctly.

Why is this happening now?

Apple released updates on August 23, 2021 for both XProtect (now version 2150) and Malware Removal Tool (now version 1.82). My assumption is that XProtect’s update included instructions to no longer accept code signing from the distrusted Symantec CAs. XProtect checks executable code on launch, so it would be working with Gatekeeper to detect and block the no-longer-trusted code signing.

What should you do?

See if your vendor has released an updated version of the app which is having problems. If they haven’t yet, I recommend contacting them to make sure they’re aware of the problem.

Hat tip to all the folks working on this issue in the MacAdmins Slack for helping diagnose the issue and why it is happening.

Every so often, you may find yourself in a situation where you need to reinstall macOS Big Sur and everything is failing on you. Installing from macOS Recovery? Not working via the usual methods. Building a USB installer? Left the flash drive in your other pants. Using DFU mode and Apple Configurator on an Apple Silicon Mac? You need a second Mac to use this process and you just have the one Mac available.

For those situations, there’s one more option when you’ve exhausted all of the others. For more details, please see below the jump.

This method is referenced in the following Apple KBase article:

https://support.apple.com/HT211983

It involves the following:

• Wiping the drive that you intend to install macOS Big Sur onto.
• Creating the proper directory structure manually on the drive.
• Copying the Install macOS app available in macOS Recovery manually into the proper location on the drive 
• Using the curl tool to download the needed installer files onto the drive
• Launching the Install macOS app
• Using the Install macOS app to install macOS Big Sur

To install macOS Big Sur using the methods described above, use the procedure below:

1. Boot to macOS Recovery.

2. Erase your Mac’s startup drive using the correct procedure for your Mac model:

Macs with Intel processors: https://support.apple.com/HT208496
Apple Silicon Macs: https://support.apple.com/kb/HT212030

By default, an erased drive is named Untitled. We’ll be using that drive name for the examples shown in this post.

2. Once the drive is erased, open Safari and go to the following URL:

https://support.apple.com/HT211983

3. Scroll to the bottom of the KBase article and locate the Or use Terminal to reinstall section.

4. Copy the complete command which begins with curl. (This will save a lot of typing later.)

5. Quit Safari.

6. Open Terminal.

7. Run the following command to change to using the drive named Untitled:

cd "/Volumes/Untitled"

8. Run the following command to create a directory named private on the Untitled drive as well as a sub-directory inside of private which is named tmp:

mkdir -p private/tmp

9. Run the following command to copy the Install macOS Big Sur.app application from macOS Recovery to the /Volumes/Untitled/private/tmp directory.

cp -R "/Install macOS Big Sur.app" private/tmp

10. Run the following command to change to the /Volumes/Untitled/private/tmp/Install macOS Big Sur.app directory:

cd "private/tmp/Install macOS Big Sur.app"

11. Run the following command to create a directory named Contents on the Untitled drive as well as a sub-directory inside of Contents which is named SharedSupport:

mkdir Contents/SharedSupport

12. Paste the copied curl command and hit the enter key on your keyboard to have the macOS Big Sur installer files be downloaded into a file named SharedSupport.dmg. The SharedSupport.dmg will be located in /Volumes/Untitled/private/tmp/Install macOS Big Sur.app directory/Contents/SharedSupport.

curl -L -o Contents/SharedSupport/SharedSupport.dmg https://swcdn.apple.com/content/downloads/01/60/071-72781-A_CZ1D1FENMH/a09fvud3xxgih7qyau9a7lhtspho36mp0l/InstallAssistant.pkg

13. Once curl has finished downloading /Volumes/Untitled/private/tmp/Install macOS Big Sur.app directory/Contents/SharedSupport/SharedSupport.dmg, run the following command to launch the macOS Big Sur installer.

./Contents/MacOS/InstallAssistant_springboard

14. Follow the prompts to install macOS Big Sur.