As Apple introduces its new Apple Silicon Macs, it’s important that Mac admins be able to identify if their environment’s software will be able to run natively on both Intel and Apple Silicon as Universal 2 apps or if they’ll need Apple’s Rosetta 2 translation service installed first on their Apple Silicon Macs to allow their apps to run.

To assist with this identification effort, Apple has provided two tools:

• file
• lipo

Both have been around for a while and initially helped identify the original Universal binaries, which were compiled to support both PowerPC and Intel processors. They’ve now been updated for this new processor transition and either will be able to identify if an app’s binary was compiled for the following:

• x86_64 (Intel)
• arm64 (Apple Silicon)
• Both x86_64 and arm64 (Universal 2)

For more details, please see below the jump.

To identify if an app is Intel-only or Universal using the lipo tool, please use the command shown below:

lipo -detailed_info /path/to/binary

For example, on macOS Catalina 10.15.7 Apple’s Safari browser is an Intel-only binary, since macOS Catalina won’t run on an Apple Silicon Mac. Running lipo on macOS Catalina 10.15.7’s Safari should produce output similar to what’s shown below:

username@computername ~ % lipo -detailed_info /Applications/Safari.app/Contents/MacOS/Safari
input file /Applications/Safari.app/Contents/MacOS/Safari is not a fat file
Non-fat file: /Applications/Safari.app/Contents/MacOS/Safari is architecture: x86_64
username@computername ~ %

Likewise, Jamf Pro 10.25.2’s jamf binary now supports both Intel and Apple Silicon. Running the lipo command described above should produce output similar to what’s shown below:

username@computername ~ % lipo -detailed_info /usr/local/jamf/bin/jamf
Fat header in: /usr/local/jamf/bin/jamf
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 6441136
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 6471680
size 6121168
align 2^14 (16384)
username@computername ~ %

To identify if an app is Intel-only or Universal using the file tool, please use the command shown below:

file /path/to/binary

Running the file command described above on macOS Catalina 10.15.7’s Safari should produce output similar to what’s shown below:

username@computername ~ % file /Applications/Safari.app/Contents/MacOS/Safari
/Applications/Safari.app/Contents/MacOS/Safari: Mach-O 64-bit executable x86_64
username@computername ~ %

Running the file command described above on the Jamf Pro 10.25.2 jamf binary should produce output similar to what’s shown below:

username@computername ~ % file /usr/local/jamf/bin/jamf
/usr/local/jamf/bin/jamf: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
/usr/local/jamf/bin/jamf (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/local/jamf/bin/jamf (for architecture arm64):	Mach-O 64-bit executable arm64
username@computername ~ %

For more information about app testing, Howard Oakley has a blog post discussing the lipo tool in more detail which I recommend checking out. I’ve linked to it below:

Magic, lipo and testing for Universal binaries:
https://eclecticlight.co/2020/07/24/magic-lipo-and-testing-for-universal-binaries/

I’ve started working with Amazon Web Service’s new macOS EC2 instances and after a while, I noticed that no matter how much EBS drive space I assigned to a EC2 instance running macOS, the instance would only have around 30 GBs of usable space. In this example, I had assigned around 200 GBs of EBS storage, but the APFS container was only using around 30 GBs of the available space.

After talking with AWS Support, there’s a fix for this using APFS container resizing. This is a topic I’ve discussed previously in the context of resizing boot drives for virtual machines. For more details, see below the jump.

To resize a macOS EC2 instance’s boot volume, you need to do two things:

1. Identify the appropriate APFS container:

APFS containers act as storage pools for APFS volumes. APFS volumes are what act as the mounted filesystem, where you store your files, directories, metadata, etc. When you grow the APFS container, the APFS volumes will likewise get additional space.

To identify the container for the instance’s boot volume, use the command shown below:

/usr/sbin/diskutil list physical external | awk '/Apple_APFS/ {print $7}'

2. Once the appropriate APFS container has been identified, use diskutil to resize the container with all available disk space.

You can specify a size of zero (0) to grow the targeted container using all unallocated drive space.

/usr/sbin/diskutil apfs resizeContainer apfs_container_id_goes_here 0

In this example, I have an instance where my APFS-formatted boot drive is using 32 GBs of space, but the instance has 200 GBs of available EBS disk space.

Assuming that the command above gave us disk1s2 as a result, the command shown below can be used to resize the boot drive’s APFS container with all available disk space.

/usr/sbin/diskutil apfs resizeContainer disk1s2 0

Once the container resizing has completed, the OS should now recognize and be able to use the now-allocated space.

This can be confirmed by other disk space measuring tools.

One of the outcomes of the recent Amazon Web Service’s Insight conference was AWS’s announcement that, as of November 30th, macOS EC2 instances were going to be available as on-demand instances or as part of one of AWS’s reduced cost plans for those who needed them long-term.

There are a few differences about AWS’s macOS offerings, as opposed to their Linux and Windows offerings. macOS EC2 instances are set up to run on actual Apple hardware, as opposed to being completely virtualized. This means that there are the following dependencies to be aware of:

1. macOS EC2 instances must run on dedicated hosts (AWS has stated these are Mac Minis)
2. One macOS EC2 instance can be provisioned per dedicated host.

AWS has also stipulated that that dedicated hosts for macOS EC2 instances have a minimum billing duration of 24 hours. That means that even if your dedicated host was only up and running for one hour, you will be billed as if it was running for 24 hours.

For now, only certain AWS regions have EC2 Mac instances available. As of December 20th, 2020, macOS EC2 instances are available in the following AWS Regions:

• US-East-1 (Northern Virginia)
• US-East-2 (Ohio)
• US-West-2 (Oregon)
• EU-West-1 (Ireland)
• AP-Southeast-1 (Singapore)

The macOS EC2 instances at this time support two versions of macOS:

• macOS Mojave
• macOS Catalina

macOS Big Sur is not yet supported as of December 20th, 2020, but AWS has stated that Big Sur support will be coming shortly.

By default, macOS EC2 instances will include the following pre-installed software:

• ENA drivers
• EC2 macOS Init
• EC2 System Monitoring for macOS
• Systems Manager SSM Agent for macOS
• AWS Command Line Interface (AWS CLI) version 2
• Xcode Command Line Tools
• Homebrew

For folks looking to build services or do continuous integration testing on macOS, it’s clear that AWS went to considerable lengths to have macOS EC2 instances be as fully-featured as their other EC2 offerings. Amazon has also either made it possible to install the tools you need or just went ahead and installed them for you. They’ve also included drivers for their faster networking options and made it possible to manage and monitor Mac EC2 instances using AWS’s tools just like their Linux and Windows EC2 instances.

That said, all of this comes with a price tag. Here’s how it works out (all figures expressed in US dollars):

mac1 Dedicated Hosts (on-demand pricing):

$1.083/hour (currently with a 24 hour minimum charge, after which billing is by the second.)
$25.99/day
$181.93/week
$9493.58/year

Now, you can sign up for an AWS Savings Plan and save some money by paying up-front for one year or three years. Paying for three years, all cash up front is the cheapest option currently available:

$0.764/hour
$18.33/day
$128.31/week
$6697.22/year

Now some folks are going to look at that and have a heart attack, while others are going to shrug because the money involved amounts to a rounding error on their existing AWS bill. I’m mainly going through this to point out that hosting Mac services on AWS is going to come with costs. None of AWS’s existing Mac offerings are part of AWS’s Free Tier.

OK, so we’ve discussed a lot of the background but let’s get to the point: How do you set up AutoPkg to run in the AWS cloud? For more details, please see below the jump.

If you’ve worked with Amazon Web Service’s EC2 service previously, getting AutoPkg up and running in AWS should be fairly straightforward. That said, if you haven’t worked with either AWS or EC2 before, there may be a bit of a learning curve. For folks in this situation, I gave a talk on Amazon Web Services which should help get you started:

Getting Started with Amazon Web Services: http://docs.macsysadmin.se/2018/video/Day4Session4.mp4

In this example, I’m going to setting up a macOS EC2 instance with the following:

• git
• AutoPkg
• AutoPkgr
• JSSImporter

Pre-requisites:

• An Amazon Web Services account
• Money (at least $25.99)

Setting up a dedicated host

To run a macOS instance in EC2, you need to first choose an actual Mac Mini to run that instance on. Amazon refers to this as a dedicated host and the process looks like this:

1. Open the Amazon EC2 web console at https://console.aws.amazon.com/ec2/.

2. In the navigation pane, choose Dedicated Hosts.

3. Choose Allocate Dedicated Host and then do the following:

For Name Tag:, give it an appropriate name.

For Instance family, choose mac1.

For Support multiple instance types, uncheck the Enable checkbox.

For Instance type, select mac1.metal.

For Availability Zone, choose the Availability Zone for the Dedicated Host. (For this example, I’m in US-East-2 and I’m choosing us-east-2b.)

For Instance auto-placement, do not check anything.
For Host recovery, do not check anything.
For Quantity, keep 1.

Click the Allocate button. (This is the part where Amazon charges you $25.99)

At this point, the Dedicated Host should be created.

Setting up a macOS EC2 instance

If you haven’t previously done so, set up an AWS SSH key pair for use with EC2 instances:

https://docs.aws.amazon.com/cli/latest/userguide/cli-services-ec2-keypairs.html

Once your keypair has been created, select the Dedicated Host that you created and then do the following:

Choose Actions, Launch instances onto host.

Select a macOS AMI. For this example, I’m selecting macOS Catalina 10.15.7.

Select the mac1.metal instance type.

Click the Next: Configure Instance Details button.

On the Configure Instance Details page, verify the following:

Tenancy: Set as dedicated host.

Host is set as the Dedicated Host you created.

Update Affinity as needed. Mine is set to Off.

In User Data, I have a script that the Mac EC2 instance can run at boot.

This user data script does the following:

Configures Mac EC2 instance with the following:

• Account password for the default ec2-user account
• Set the Mac to auto-login as the default ec2-user account
• git
• AutoPkg
• AutoPkgr
• JSSImporter

Once these tools and modules are installed, the script configures AutoPkg to use the recipe repos defined in the AutoPkg repos section.

If you want to use this user data script, it’s available from the following address on GitHub:

https://github.com/rtrouton/aws_scripts/tree/master/setup_mac_ec2_instance_for_autopkg

Before adding the user data script to the instance build process, check the variables in the script and verify that they are set up the way you want. There is also an upper limit of 15K in size for this script.

From there, either copy and paste the script into the available user data blank or select the user data script as a file.

Double-check your Tenancy, Host and User Data settings to make sure everything is set as desired, then click the Next: Add Storage button.

Set how much storage you want. For this example, I’m setting it at 60 GBs of storage.

Note: Depending on how many AutoPkg recipes you’re running and the size of the installers, you may want to double or even triple the amount of storage I’m setting. Another thing to be aware of is that, the instance’s boot volume will need to be resized to recognize the additional space. If using the user data script linked above, boot volume resizing is included as part of the script’s run.

Once storage is set, click the Next:Add Tags button.

Set tags as desired, then click the Next: Security Group button.

Choose the options to set a security group as desired.

If you don’t have a security group available, I recommend creating one and setting it to allow SSH from only your IP address, then click the Review and Launch button.

Review your instance’s settings and make sure everything is OK. Once you’re sure, click the Launch button.

When prompted, select your SSH keypair, then click the Launch instances button.

Your Mac instance will now launch on the dedicated host. To see if it in the Instances list, click the View instances on host button.

To find out its public DNS address and other useful information, click on the instance ID.

Wait about fifteen minutes for your instance to finish setting itself up. After that you should be able to connect to it via SSH and (assuming you configured the right variables for VNC access) also via remote screen sharing.

Connecting to the macOS EC2 instance following setup

Following setup, you can connect to the newly-built EC2 instance via SSH. To do so, open Terminal and use the following SSH command:

ssh -i /path/my-key-pair.pem ec2-user@my-instance-public-dns-name

For example, if your SSH keypair was stored in ~/.ssh and named AutoPkg_SSH_Keypair.pem, you would use the following command to connect to a macOS EC2 instance whose address is ec2-3-23-97-197.us-east-2.compute.amazonaws.com:

ssh -i ~/.ssh/AutoPkg_SSH_Keypair.pem ec2-user@ec2-3-23-97-197.us-east-2.compute.amazonaws.com

No password is needed in this case, as you are using your SSH keypair to authenticate the SSH session.

To connect via VNC, I recommend setting up VNC to run over an SSH tunnel. The reason for this is that VNC by default does not encrypt its traffic so all network communication between you and the instance (including any passwords) would be sent in the clear. Using an SSH tunnel will allow you to wrap this unencrypted traffic inside SSH’s encryption, which should secure it against third parties.

To set up VNC to run inside an SSH tunnel, you will need to first set up a password for the ec2-user account if you haven’t done so already. You can do this by connecting to the instance via SSH and running the following passwd command:

sudo passwd ec2-user

Once the command has been run, follow the prompts to change the password. Once the password is set up, run the following SSH command on your end:

ssh -L 5900:localhost:5900 -i /path/my-key-pair.pem ec2-user@my-instance-public-dns-name

For example, if your SSH keypair was stored in ~/.ssh on your Mac and named AutoPkg_SSH_Keypair.pem, you would use the following command to set up an SSH tunnel for VNC between your Mac and a macOS EC2 instance whose address is ec2-3-23-97-197.us-east-2.compute.amazonaws.com:

ssh -L 5900:localhost:5900 -i ~/.ssh/AutoPkg_SSH_Keypair.pem ec2-user@ec2-3-23-97-197.us-east-2.compute.amazonaws.com

Once that’s done, do the following:

1. Under the Go menu, select Connect to Server.
2. In the Connect to Server window, enter the following:

vnc://localhost:5900

When prompted, use the following username and password:

Username: ec2-user
Password: Whatever password you defined in the script for the ec2-user account to use.

Once connected, you’ll be able to work with the Mac instance like you would any other remotely-accessible Mac.

In the case of a AutoPkg server built using the user data script I linked to above, you could open AutoPkgr and start setting up your recipes to begin scheduled runs.

After 24 years and 1078 known security vulnerabilities, Adobe Flash has reached end of life status as of December 31, 2020.

To assist with the process of removing Adobe Flash, I’ve written an uninstall script which will completely remove Adobe Flash. For more details, please see below the jump.

This script is designed to uninstall the Adobe Flash plug-ins and their associated components. As part of this, it runs the following actions:

1. Stop Adobe Flash Install Manager
2. If running, unload the launchdaemon used by the Adobe Flash update process.
3. Remove the Adobe Flash plug-ins, Adobe Flash Install Manager and their associated components.
4. Remove Adobe Flash preference pane settings at the user level.
5. Forget the installer package receipts.

The script is available below and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/uninstallers/adobe_flash_uninstall

As new Apple Silicon Macs (ASM) have begun making their way to organizations which use FileVault encryption to secure their fleets, a difference between Intel Macs and ASMs has become apparent.

Intel Macs:

• Supports account icons and password blanks at the FileVault login screen
• Unable to support username blanks at the FileVault login screen
• Unable to support smart cards for login at the FileVault login screen

ASMs:

• Supports account icons and password blanks at the FileVault login screen
• Supports username and password blanks at the FileVault login screen
• Supports smart cards for login at the FileVault login screen

Why the differences between platforms? For more details, please see below the jump.

Intel Macs

On Intel Macs, Apple is dependent on using the EFI login environment for the FileVault 2 login screen. This is a very limited environment in terms of functionality and is used in the FileVault 2 context to provide a way to boot the Mac while the main boot volume is locked by FileVault’s encryption. Once EFI has booted the Mac, the Mac then uses authentication from the user and the tools stored on the not-encrypted Preboot volume to unlock the much-larger encrypted boot volume.

EFI’s limitations mean that only a password blank is truly supported, with Apple having pushed the limits to support correctly matching up multiple account icons with the corresponding multiple account passwords.

Apple Silicon Macs

On ASMs, there is now a unified macOS login experience which includes FileVault logins. For details on this, I recommend checking out the Explore the new system architecture of Apple Silicon Macs session video from WWDC 2020. The explanation is available starting around 20:14.

On Apple Silicon Macs, macOS has a unified log-in experience. It supports a richer UI with accelerated graphics that is also consistent with macOS look and feel. This experience is made possible by fully booting macOS without requiring the user to unlock the system.

The unified log-in experience allows the introduction of new features even when FileVault is on. For example, it now has built-in support for authentication with CCID and PIV-compatible smart cards, as well as VoiceOver support for accessibility improvements.

In summary, the reason the FileVault login screen is different on ASMs is that Apple no longer needs to use the EFI login environment. Instead, ASMs are able to fully boot macOS while still securing user data within a locked volume which is protected by FileVault.

This is a huge leap forward for ASMs in terms of FileVault login functionality, as there is no longer a login functionality divide between enabling FileVault and not enabling FileVault. As of macOS Big Sur and the M1 ASMs, FileVault logins should now be able to use whichever authentication methods are supported by macOS. More importantly for the future, as native support for new authentication methods are added to the OS, FileVault logins should be able to use them natively as well.

Nine years ago, I wrote a post on how I backup this blog. Overall, the reasons I’m backing up haven’t changed:

• I like this blog and don’t want to see it or its data disappear because of data loss.
• WordPress.com’s free hosting doesn’t provide me with an automated backup method.

To create the backups, I make a nightly mirror using HTTrack. As time has passed and host machines were replaced, I’ve moved the backup host a few times. For the last move, I decided for budgetary reasons to move off of using Macs and onto a Raspberry Pi. For those wanting to know more, please see below the jump.

The current backup host is a Raspberry Pi 3 Model B running Raspbian Buster, which is closely based on Debian Linux. To set up an automated backup using HTTrack, I used the following procedure:

1. Installed HTTrack for Debian by running the commands below with root privileges:

apt-get update
apt-get install webhttrack

2. Creating a backup directory in the pi user’s home directory by running the following command:

mkdir -p /home/pi/derflounder_backup

2. Set up the following script as /usr/local/bin/der_flounder_backup.sh

#!/bin/bash

backupDirectoryPath="/home/pi/derflounder_backup"

/usr/bin/httrack "https://derflounder.wordpress.com/" -O "$backupDirectoryPath" "+https://derflounder.wordpress.com/*" "+https://derflounder.files.wordpress.com/*" -v

For the script itself:

• I’m first specifying the starting point. In this case, it is https://derflounder.wordpress.com/.
• We can specify where the mirrored data will go using the -O flag (note that $backupDirectoryPath is a path I defined earlier on in my script. In this case, the data is being stored in /home/pi/derflounder_backup.
• The quotations where I have “+” with something are urls from which it is allowed to download, and process. If you do not specify any, it will only download from the domain you specify.
• The “-v” flag specifies httrack to run in verbose mode.

4. Set up a cron job like the one shown below to run the backup script. In my case, I set it up in the pi user’s crontab to run nightly at 2:00 AM:

0 2 * * *  /usr/local/bin/der_flounder_backup.sh

Meanwhile, like the Macs who did this job before it, I’m also backing up the Raspberry Pi that the backup is stored on, so that I have multiple copies of the backed-up data available.

One of the changes in macOS Big Sur is that the softwareupdate command has been updated with new functionality.

Among the changes is the ability to scan Apple’s Software Update feed and display a list of the currently available full OS installers. To access this list, run the command below with root privileges:

softwareupdate --list-full-installers

The list you receive will be dependent on whether or not your Mac can run a particular OS version. As an example, here’s the list you would receive inside of a VMware VM as of March 3rd, 2021.

Once you have the right macOS installer identified, you can use the softwareupdate tool to download it.

One thing to be aware of is that multiple versions of a macOS full installer may show up in the Software Update feed. As an example of this, the list above includes multiple entries for macOS 10.15.6 and 10.15.7. These installers would be for hardware-specific builds of that macOS version’s full installer. Unfortunately, it’s not easy to tell the various installers apart using the softwareupdate command because the build number is not included.

If you do need to be able to download an installer with a specific build number, I recommend using the installinstallmacos.py tool. This tool also references the Apple Software Update feed, so the information you get back should be similar but also include the relevant build numbers for the macOS full installers.

One of my personal preferences with macOS is removing the drop shadow from screenshots. On macOS Catalina and earlier, I was able to to turn off drop shadows on screenshots by running the following commands:

defaults write com.apple.screencapture disable-shadow true
killall SystemUIServer

This appears to not work on fresh installs of macOS Big Sur, though it appears to still work on Big Sur Macs who had the setting applied prior to upgrading to Big Sur. However, when using keyboard shortcuts to make screenshots, it looks like there’s a way to selectively add or remove the drop shadow at the time of making the screenshot. For more details, please see below the jump.

To take a screenshot of window or menu with a drop shadow:

1. Click Command + Shift + 4 + Spacebar
2. Wait for the mouse pointer to change into a camera icon.
3. Click on the window to take the screenshot.

The screenshot should be taken and have a drop shadow.

To take a screenshot of window or menu without a drop shadow:

1. Click Command + Shift + 4 + Spacebar
2. Wait for the mouse pointer to change into a camera icon.
3. Hold down the Option key
4. Click on the window to take the screenshot.
5. Release the Option key

The screenshot should be taken and not have a drop shadow.

As part of many application or package building workflows, there is a requirement to sign the end result to guarantee that the app or package has not been tampered with. With the advent of Apple’s notarization process, this has become even more important because an app or installer package must be signed before it can be notarized.

However, in order to sign apps or packages, you must have the signing certificate available. This has often meant putting copies of Apple signing certificates, complete with the certificate’s private key, onto the Mac or Macs used to build the application and/or installer package. This has security concerns because if the signing certificate’s private key is compromised, you must now revoke the existing certificate, get a new one from Apple and re-sign everything that used that now-revoked signing certificate.

To assist with the security concerns, Twocanoes Software has developed Signing Manager. This tool provides a way to centralize hosting of signing certificates and make their signing capabilities securely available to Macs which need them. In my own case, I’m investigating Signing Manager in the context of signing AutoPkg-built installer packages. For more details, please see below the jump.

Signing Manager consists of a server which hosts certificates and a client which logs into the server using an API key. Let’s take a look at how you set up a certificate to be shared. In this example, I’ll be using Twocanoes’ own signing server and a sample Package Signing certificate.

Importing the signing certificate into the Signing Manager server

Pre-requisites:

• Signing certificate’s public and private keys stored in a .p12 file
• The password to unlock the .p12 file

1. Log into the Signing Manager server.
2. Make note of the Signing Server Domain URL and API key. You’ll need them later with the Signing Manager client software.

3. Click on the Identities link.

3. Click on the Import Identity button.

4. Select your signing certificate’s .p12 file and enter the password for it into the password blank.

5. Click the Import button.

Your certificate should now be imported.

Enabling the signing certificate for access on a client Mac.

1. Install the Signing Manager client software.
2. In the Signing Manager, set the following:

• In the Signing Server blank, enter the Signing Server Domain URL.
• In the API Key blank, enter the API key

Once entered and verified, click the OK button.

3. You should now see the certificate appear in the Signing Manager app window, along with a notification that a smartcard has been inserted.

Signing Manager sets up a virtual smart card with the signing certificate’s information stored inside. Your Mac should be able to work with the certificate information on this virtual smart card like it can with certificates stored in your Mac’s own keychain files.

The Signing Manager client software also includes several useful features:

1. Copying the Common Name from the certificate:

Clicking the Copy CN button will add the Common Name of the selected certificate to the clipboard.

2. Copying the Fingerprint, or SHA1 hash of the certificate to the clipboard.

Clicking the Copy Fingerprint button will add the SHA1 hash of the selected certificate to the clipboard.

Note: The Fingerprint name is what will be used as the certificate name when signing.

3. Copying an example codesign command with certificate name to clipboard.

Clicking the Copy codesign command button will copy the example codesign command to the clipboard.

4. Copying an example productsign command with certificate name to clipboard.

Clicking the Copy productsign command button will copy the example productsign command to the clipboard.

5. Displaying certificate information

Clicking the Show Certificate button will display information about the selected certificate.

Signing an AutoPkg-built installer package

In most ways, using a Signing Manager-hosted certificate for signing is identical to using a certificate stored in a Mac’s keychain. The main difference will be the name of the certificate, as Signing Manager will use the Fingerprint identifier for the certificate. Specifically, you can use Apple’s codesign and productsign tools with a Signing Manager-hosted certificate just like you would a certificate stored locally on your Mac inside a keychain.

This similarity allows it to be easily integrated into an AutoPkg workflow which uses the PkgSigner processor. This AutoPkg processor uses productsign to do the following:

1. Identify an unsigned package built by an AutoPkg recipe.
2. Rename the unsigned package from /path/to/package_name_here.pkg to /path/to/package_name_here-unsigned.pkg.
3. Sign the package.
4. Save the signed package as /path/to/package_name_here.pkg, so that the name matches the original package. Renaming the signed package to match the original unsigned package’s name allows AutoPkg to continue to work with the now-signed installer package.

The main difference should be that a keychain-stored certificate would be named something like this:

Developer ID Installer: Rich Trouton (XF95CST45F)

The Signing Manager-hosted certificate would instead be identified by the Fingerprint value, which may look something like this:

4A72196F535A51A98FF2480132F024222B65060C

With that in mind, let’s take a look at how a Signing Manager-hosted certificate could be integrated into an AutoPkg workflow, using a process I’ve written about previously.

For this example, a .pkg recipe for Postman which includes the PkgSigner processor is being used:

An override of the recipe would be needed, in order to include the Fingerprint value from Signing Manager into the SIGNINGCERTIFICATE key’s value in the recipe override.

When the recipe override is run in verbose mode, the Fingerprint value shows up as the signing certificate used to successfully sign the certificate using the PkgSigner processor:

By itself, Signing Manager is an amazing tool. For those interested in using AutoPkg on a cloud service or as part of a continuous integration workflow, it opens up all kinds of possibilities because it means it’s no longer necessary to have one or multiple copies of your signing certificates on the same Macs where you’re running AutoPkg. Now you can have your signing certificate stored in a secured central place and also have it available on-demand to remote clients in a secure manner.

As part of the release notes for Jamf Pro 10.28, there is this note in the Deprecations and Removals section:

Support ending for the Jamf Pro Server Installer for macOS — Support for using the Jamf Pro Installer for macOS will be discontinued in a future release. Mac computers with Apple silicon are not supported by the Jamf Pro Installer for macOS. 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 from macOS to one of the following servers: Red Hat Enterprise Linux, Ubuntu, or Windows. For more information, see the Migrating to Another Server Knowledge Base article.

For those folks who are running on-premise Jamf Pro servers on Macs, it looks like it’s time to contact Jamf Support and plan a migration if you haven’t already. As of March 17th, 2021, Jamf’s published support for running Jamf Pro includes the following OS, database and Java versions:

When folks have needed command line access to instances running in Amazon Web Service’s EC2 service, SSH has been the usual method used. However, in addition to using SSH to connect to EC2 instances in AWS, it is also possible to connect remotely via Session Manager, one of the services provided by AWS’s Systems Manager tool.

Session Manager uses the Systems Manager agent to provide secure remote access to the Mac’s command line interface without needing to change security groups and allow SSH access to the instance. In fact, Session Manager allows remote access to EC2 instances which have security groups configured to allow no inbound access at all. For more details, please see below the jump.

To access EC2 instances via Session Manager, please use the procedure shown below:

1. Verify that the Systems Manager agent is installed and configured properly.
2. Select the desired EC2 instance.

3. Click the Connect button.

4. In the Connect to instance window, select the Session Manager tab then click the Connect button.

5. A new browser window will open up.

Note: The active user at this point is the Systems Manager agent’s user account, which is ssm-user.

To get access to the ec2-user account (the default account used on most EC2 instances running macOS or Linux), you’ll need to switch accounts. To do this, run the command shown below to change to the ec2-user account:

sudo su ec2-user

6. You should now be logged in as the ec2-user account.

To close the remote session, use the procedure shown below.

1. Verify that all work has been completed.
2. Click the Terminate button.

3. When prompted for confirmation, click the Terminate button.

For those using Jamf Pro’s Self Service, one of the handier features can be the Search function built into the app. This search is able to examine Self Service policies and use the information in the policy and Self Service description to populate its search results. For the most part, just the displayed information in the policy should allow Self Service’s search to display relevant policies.

However, you may have a need to force the search process to include policies that would otherwise fall outside of the search parameters. For those who need this ability, thanks to Self Service’s support of Markdown it’s possible to invisibly add search keywords to a Self Service policy description. For more details, please see below the jump.

Markdown is a markup language which uses specific syntax to produce formatted text. In the image below, the left side shows what appears in the Markdown editor and the right side shows how the formatted document would appear.

Among the syntax options is the ability to add comments using the HTML comment tag. These show up in the Markdown editor, but they don’t show up in the displayed document.

Since Self Service descriptions only display the formatted text, but the search function can search everything in the description, we can use the comment syntax to add search keywords which Self Service’s search can use but which are invisible to someone looking at the Self Service description via the Self Service app.

To add search keywords, add the syntax tags for Markdown commenting to your Self Service description and add the search keywords you want to use within the tags. An example is shown below:

<!-- Search Keywords Go Here -->

For example, if you wanted to add search keywords like Java and JDK to a Java install policy, you could add the following to your Self Service description:

<!--Java, JDK-->

Even if the displayed text in the policy or the Self Service description never mentions either Java or JDK, Self Service’s search will include this policy when you search for those terms.

Here’s another example, using Backup as a search keyword:

<!--Backup-->

Note: Self Service’s search is case-insensitive so searching for backup or BACKUP when you have Backup as the search keyword should also display the relevant policy or policies.

If you’re using AutoPkg and tools like jamf-upload or JSSImporter to automate the uploading of packages and scripts to your Jamf Pro server, it may be necessary to periodically delete a large number of now-obsolete installer packages or scripts from your server. To help with this, I’ve written a couple of scripts to help automate the deletion process by using a list of Jamf IDs and the API to perform the following tasks:

1. Delete the relevant installer packages or scripts.
2. Generate a report of which packages or scripts were deleted.

For more details, please see below the jump.

Both scripts work with a text file of Jamf Pro IDs, and also include error checking to make sure that the text file’s entries contained only positive numbers.

To use these scripts, you will need four things:

1. A text file containing the Jamf Pro package or script IDs you wish to delete.
2. The address of the appropriate Jamf Pro server
3. The username of an account on the Jamf Pro server which has the necessary privileges to delete computers and/or mobile devices.
4. The password to that account.

The test file should contain only the relevant Jamf Pro IDs and appear similar to this:

Once you have the text file and the other prerequisites, the scripts can be run using the following commands:

To delete installer packages:

/path/to/delete_Jamf_Pro_Packages.sh /path/to/text_filename_here.txt

To delete scripts:

/path/to/delete_Jamf_Pro_Scripts.sh /path/to/text_filename_here.txt

For authentication, the scripts 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

It is also possible to simulate a run of the script, to make sure everything is working before running the actual deletion. To put the script into simulation mode, comment out the following line of the script.

delete_Jamf_Pro_Packages.sh

/usr/bin/curl -su ${jamfpro_user}:${jamfpro_password} "${jamfproIDURL}/$PackagesID" -X DELETE

delete_Jamf_Pro_Scripts.sh

/usr/bin/curl -su ${jamfpro_user}:${jamfpro_password} "${jamfproIDURL}/$ScriptsID" -X DELETE

To take it out of simulation mode and enable deletion, uncomment the line.

In simulation mode, you can test out if the script is reading the text file properly and the authentication method. For example, the following output should be seen in simulation mode if the text file is being read properly and manual input is being used.

username@computername ~ % /path/to/delete_Jamf_Pro_Scripts.sh ~/Desktop/home_scripts_report.txt

Please enter your Jamf Pro server URL : https://jamf.pro.server.goes.here:8443
Please enter your Jamf Pro user account : jpadmin
Please enter the password for the jpadmin account:
Deleting iscasperonline.sh - script ID 13.

Deleted iscasperonline.sh - script ID 13.

Deleting xcode_uninstall.sh - script ID 15.

Deleted xcode_uninstall.sh - script ID 15.

Report on deleted scripts available here: /var/folders/wz/mp27mjl97h505nvff787hh3c0000gn/T/tmp.IaiOiHgI.tsv
username@computername ~ %

The following output should be seen in production mode if the text file is being read properly and the needed values are being read from a ~/Library/Preferences/com.github.jamfpro-info.plist file.

username@computername ~ % /path/to/delete_Jamf_Pro_Scripts.sh ~/Desktop/home_scripts_report.txt

Deleting iscasperonline.sh - script ID 13.
<?xml version="1.0" encoding="UTF-8"?><script><id>13</id></script>
Deleted iscasperonline.sh - script ID 13.

Deleting xcode_uninstall.sh - script ID 15.
<?xml version="1.0" encoding="UTF-8"?><script><id>15</id></script>
Deleted xcode_uninstall.sh - script ID 15.

Report on deleted scripts available here: /var/folders/wz/mp27mjl97h505nvff787hh3c0000gn/T/tmp.vZgL8WOk.tsv
username@computername ~ %

Once the script has completed its run, it will generate a report on the deleted items in tab-separated format and display the .tsv file’s location.

The scripts are available below, and at the following addresses on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/delete_Jamf_Pro_Packages

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/delete_Jamf_Pro_Scripts

delete_Jamf_Pro_Packages.sh:

delete_Jamf_Pro_Scripts.sh:

I use AutoPkg and JSSImporter to keep my Jamf Pro server updated with the latest installers for the software used by my shop. However, this means that I usually have a large number of no-longer-needed installers stored in my Jamf Pro server’s distribution point and I need to periodically clear the obsolete packages out by deleting them. Recently, as part of removing 500+ unneeded packages from Jamf Pro using a script, I noticed the following behavior occurring:

1. Run an API command similar to the one below:

username@computername ~ % /usr/bin/curl -su username:'password' "https://jamf.pro.server.here/JSSResource/packages/id/1213" -X DELETE

2. Long pause (around 60 seconds)
3. Receive the following output:

<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>

4. Check the package and it has been deleted from Jamf Pro.

The 504 Gateway Time-out error indicated that either the load balancer in front my Jamf Pro server was timing out before the API command could report success or failure. I was seeing this behavior when running the API commands manually or as part of a script, so I decided to see if I saw the same behavior when deleting the package from the Jamf Pro admin console. When I checked, I did.

I sent in a support request to Jamf to ask about this and there is a PI open for this:

PI-009627: Having a large amount of packages uploaded to a distribution point can cause various timeouts

For others experiencing this issue, while Jamf addresses this product issue, the workaround for the timeout issue is (if possible) to increase the timeout value. In my case, increasing the load balancer timeout from 60 seconds to 120 addressed the timeout issue and allowed my API and GUI package deletions to complete successfully without timing out.

Note: This does not fix the issue of the package deletion taking a while. It just makes sure that the deletion command, either via the API or using the GUI in the admin console, doesn’t timeout before reporting success or failure.

As part of preparing for an upcoming talk, I’m working on a presentation which includes a video. As part of adding the video to my Keynote slides I thought that increasing the playback speed would help with the pacing of the talk but I didn’t see a way in Keynote to have that happen as part of the video’s playback without having to manually run the video.

After some research, I found a straightforward way to use the open-source VLC video tool to double the playback speed of a video and save the changes. For more details, please see below the jump.

Pre-requisites:

• VLC
• Video file in an input format understood by VLC

To have VLC read a video file and save it as a new file which plays at twice the speed of the original file, please use the process below:

1. Open VLC
2. Under the File menu, select Convert / Stream…

3. In the Convert & Stream window, click the Open media… button.

4. Select the video where you want to increase the playback speed.
5. Select the video profile you want. (In this case, I’m selecting the default option: Video – H.264 + MP3 (MP4) )
6. Click the Customize… button

7. Set the Scale option to 2.

8. Click the Apply button.

9. In the Choose Destination section of the Convert & Stream window, click the Save As File button.

10. Choose the name and location to save the sped-up file.

10. Click the Save button.

VLC will then do the following:

1. List the file in its playlist.
2. Play back the original file at two times normal speed.
3. Record the original file’s playback to the new file. In this case, because I chose the Video – H.264 + MP3 (MP4) profile, the new file is saved as an .m4v file.

I’ve recently been working with Twocanoes Software’s Signing Manager in combination with my autopkg-conductor tool for managing AutoPkg runs. I’m happy to report it’s possible, but you may need to make some adjustments to how autopkg-conductor is being launched. For more details, please see below the jump.

As originally written, autopkg-conductor uses a LaunchDaemon to manage when the autopkg-conductor script is run. This was an idea I adopted from AutoPkgr, which also uses a LaunchDaemon to perform AutoPkg runs. The reason for using a LaunchDaemon is that the LaunchDaemon will be able to perform the scheduled AutoPkg run regardless of if the Mac is logged in at the loginwindow or not.

For the most part, this works fine to successfully trigger the autopkg-conductor script. However, a problem occurred once Signing Manager was added to the mix and I tried using it with the PkgSigner AutoPkg processor. The reason for this is that Signing Manager puts credentials into the login keychain and the user context was not correct to access those credentials. Instead, I was seeing errors like this when the LaunchDaemon triggered a run of autopkg-conductor:

After Twocanoes Support did some research, they recommended adding the following key to autopkg-conductor‘s LaunchDaemon:

Key: SessionCreate
Value: true

My LaunchDaemon now looked like this: