Archive

Archive for the ‘Packaging’ Category

Creating a NexThink uninstaller for deployment via Jamf Pro

December 4, 2022 Leave a comment

As a follow-up to my previous post on building an installer for NexThink Collector which could be deployed via Jamf Pro, I also needed to build an uninstaller for this software. Fortunately, NexThink ships an uninstaller script on the same disk image that it uses to ship its installer.

Screenshot 2022 12 03 at 3 31 46 PM

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing the following to run the uninstall process:

A. Mounting the disk image
B. Opening the Terminal application
C. Using the uninstaller script to run the uninstallation process.

Screenshot 2022 12 03 at 3 47 10 PM

In my case, I decided to do the following to deploy the uninstaller via Jamf Pro:

  1. Wrap the disk image inside a separate installer package.
  2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Use the uninstall script to uninstall the NexThink Collector software.
D. Unmount the disk image.

For more details, please see below the jump.

Read more…

Creating a NexThink installer for deployment via Jamf Pro

December 3, 2022 Leave a comment

A while back, I had to build an installer for NexThink Collector which could be deployed via Jamf Pro. NexThink can be interesting to deploy because the installation process:

  1. Involves an application named csi.app, which has a command line tool.
  2. The referenced csi app’s command line tool configures and runs an installer package.
  3. The command line tool also needs to reference a license file, which NexThink refers to as a CustomerKey file.

The CustomerKey file should look similar to what’s shown below:


—–BEGIN CUSTOMER KEY—–MIIDhzCCAm+gAwIBAgIEIa+KoTANBgkqhkiG9w0BAQsFADBbMScwJQYDVQQDDB5SZWdlcnkgU2VsZi1TaWduZWQgQ2VydGlmaWNhdGUxIzAhBgNVBAoMGlJlZ2VyeSwgaHR0cHM6Ly9yZWdlcnkuY29tMQswCQYDVQQGEwJVQTAgFw0yMjEyMDIwMDAwMDBaGA8yMTIyMTIwMjIwMDIxMFowSTEVMBMGA1UEAwwMbG9jYWxob3N0LmlvMSMwIQYDVQQKDBpSZWdlcnksIGh0dHBzOi8vcmVnZXJ5LmNvbTELMAkGA1UEBhMCVUEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaKRW9KeX4wg/838FkxmzaBjqf1DeKD5GKEqhUKz0y78Wwnsv2zAXGM4UkdZJP9zHtC9/wFQT+lhclDlogxkU9lfMADV7nMdGL0GkJzwMQNS52dPNXDup7/d9yRkyjkV0Pf4t2fJF3igoNXFQuBvuArkNV6hfja2gOEczOSAaJ7L7qRnSahLjciJRaCuEPjwneh3krhOFT+djwuYJMIvBDEqs+gfp4OPDDBtVg2scUUGRmHsC+JAoK+JwqYwB9TNt+9hZtGfDqgZSHebXEfRTguhQpBj0mPTo76EahAbHbXJhV+efg3jt32pZ6qRl8ffrZAjefWEAnOMyXQ7fbL+bpAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zAfBgNVHSMEGDAWgBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zANBgkqhkiG9w0BAQsFAAOCAQEAhpbntg+nwhIKgRuUidu/wXn197Ah0Pd4CYYxG5dR9rg8nWObx4QO6ApIH91nUUQVuV6mSTFtfy4yNQzxaROgZP9hDNvhd78D/ewXxp6bN/Xkn+c7SWrs/b1vHb2Dr1sDP4F9SAOrCI6TdoYa8UNhPXXSTt8M/hGSB2oWOpT2FAb2IbdmdYhDaibcJwp+/Had1FLbeDZgdgYCFoZLjws/9E/pIXjSxBYAJLbaQZffrfO5jCe2KesE73iQatW2IPynsFifRGGoMHXVLOfsLA9c2KDGqDmnJ+PvsBSe9rIpSJYC4WjR5Mt8W88kQSj05b9NqCsXmmMDEbD8uVLyKvQihA==—–END CUSTOMER KEY—–

All the needed components with the exception of the CustomerKey file, which is different for each customer, ship on a disk image.

Screenshot 2022 12 02 at 3 31 46 PM

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing one of the following:

Graphical installation: Mounting the disk image, double-clicking on the installer package and following the prompts, entering the correct configuration information were needed.

Screenshot 2022 12 02 at 3 46 29 PM

 

Screenshot 2022 12 02 at 3 46 39 PM

Command line installation: Mounting the disk image, opening the Terminal application and using the csi app’s command line tool to configure the installer package and run the installation process.

Screenshot 2022 12 02 at 3 46 53 PM

 

Screenshot 2022 12 02 at 3 47 02 PM

 

For the Enterprise Deployment section of the application, the NexThink documentation says they support it but doesn’t provide information on how to do it.

Screenshot 2022 12 02 at 3 47 10 PM

In my case, I decided to do the following to deploy it via Jamf Pro:

  1. Wrap the disk image and CustomerKey file inside a separate installer package.
  2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Identify the location of the csi.app on the mounted disk image.
D. Identify the location of the CustomerKey file stored inside the installer package.
E. Use the csi app’s command line tool to configure and run the NexThink-provided installer package on the mounted disk image, to install the NexThink Collector software.
F. Unmount the disk image.

For more details, please see below the jump.

Read more…

Building a Privileges installer package using AutoPkg

April 20, 2022 Leave a comment

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

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

Screen Shot 2022 04 20 at 3 45 38 PM

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


computername:~ username$ autopkg search com.github.rtrouton.Privileges
Name Repo Path
—- —- —-
Privileges.munki.recipe apfelwerk-recipes Privileges/Privileges.munki.recipe
Privileges.install.recipe rtrouton-recipes Privileges/Privileges.install.recipe
Privileges.munki.recipe rtrouton-recipes Privileges/Privileges.munki.recipe
Privileges.jss.recipe rtrouton-recipes JSS/Privileges.jss.recipe
Privileges.pkg.recipe rtrouton-recipes Privileges/Privileges.pkg.recipe
Privileges.download.recipe rtrouton-recipes Privileges/Privileges.download.recipe
To add a new recipe repo, use 'autopkg repo-add <repo name>'
computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

For more details, please see below the jump.

Read more…

Payload-Free Package Creator 2.4 now available

April 3, 2022 Leave a comment

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

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

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

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

Simple Package Creator 1.5 now available

April 2, 2022 Leave a comment

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

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

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

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

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

October 11, 2021 Leave a comment

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.

Read more…

Packaging a SAP GUI installer application for macOS

July 26, 2021 1 comment

One of the recent changes for the macOS version of SAP GUI for Java is that both SapMachine Java 11 and OpenJFX 11 are now bundled with SAP GUI, so it is no longer required to have Java installed on your machine in order for SAP GUI to work. This change has also been extended to the SAP GUI installer, which is now available as a notarized installer application as of SAP GUI 7.70.

You can run this installer on a Mac which does not have Java already installed and it will install SAP GUI for Java with SapMachine Java 11 and OpenJFX 11 installations embedded inside the SAP GUI application.

Note: As of SAP GUI 7.70 rev 2, Rosetta 2 is required if installing on an Apple Silicon Mac so Rosetta needs to be installed and running before installing SAP GUI.

The installer application is available for download to customers via a link on the announcement blog post:

https://blogs.sap.com/2021/03/16/ann-sap-gui-for-java-7.70-available-for-download/

When you click the download link, you will see two choices:

  • DMG
  • JAR

Screen Shot 2021 07 26 at 9 52 31 AM

The DMG download will provide the notarized installer application and the JAR download will provide the Java .jar installer that SAP GUI has traditionally used on macOS. I’ve discussed how to package the .jar installer in previous posts, so this post is going to focus on the new installer application contained inside the DMG download.

Screen Shot 2021 07 26 at 9 52 32 AM

For more details, please see below the jump.

Read more…

PkgSigner AutoPkg processor updated for Python 3

July 31, 2020 Leave a comment

A while back, I discussed how to incorporate installer package signing into AutoPkg workflows. The PkgSigner processor used in this workflow was originally written by Paul Suh and it uses Apple’s productsign tool to access a Developer ID Installer certificate stored in the login keychain.

Like other processors and AutoPkg itself, PkgSigner needed updating to Python 3 when Python 2 reached end-of-life in April 2020. This updating process has been completed, thanks to Nick McDonald. To make sure PkgSigner is consistently using the same Python environment across machines, PkgSigner has also been set to use the Python 3 install bundled with AutoPkg.

For those who need it, I have a copy of the PkgSigner processor available via the link below:

https://github.com/rtrouton/AutoPkg_Processors/tree/master/PkgSigner

Categories: AutoPkg, Packaging

Building customized postinstall scripts for AutoPkg recipes

July 26, 2019 Leave a comment

As part of some recent work, I needed to build a deployable installer package for an application named Zscaler. This application does not use an installer package, nor can it be installed as a drag-and-drop app. Instead, it uses a third party installer application to install.

Screen Shot 2019 07 26 at 4 36 20 PM 1

This is exactly the kind of situation where I want to write an AutoPkg recipe to handle building a deployable installer package for me. As part of that, I had two bits of good news:

  1. There was a publicly available download URL for the Zscaler installer app.
  2. Zscaler has instructions for installing from the command line, so I could wrap up the installer application inside an installer application and use a postinstall script to run the installation process.

Screen Shot 2019 07 26 at 2 51 06 PM

I had one bit of bad news:

The installer process included options for adding things like the Zscaler cloud instance which the app should talk to following the installation as well as various other options which probably shouldn’t be hardcoded into an Autopkg recipe. I especially shouldn’t be hardcoding my own organization’s credentials into a recipe which I was planning to share with other folks.

Normally, sensitive information is something I want to only have in an AutoPkg recipe override. Recipe overrides are locally-stored files that allow you to change certain input variables in AutoPkg recipes. Since the recipe overrides are stored locally on the Mac which is running AutoPkg and not shared with any other resources, the sensitive information is only made available to the AutoPkg installation running on that specific Mac. I’ve used this approach previously for the following:

Sensitive URLs: https://derflounder.wordpress.com/2017/06/12/autopkg-recipes-for-apple-enterprise-connect/
Signing AutoPkg-generated installer packages: https://derflounder.wordpress.com/2017/11/10/adding-installer-package-code-signing-to-autopkg-workflows/

This time though, I didn’t see a way to pass an AutoPkg recipe override’s variables to a postinstall script. I did have one idea though, which was using AutoPkg’s FileCreator processor to create a customized postinstall script. I had previously used the FileCreator processor in other AutoPkg recipes to create postinstall scripts, but those scripts were self-contained and didn’t use variables from the AutoPkg recipe.

AutoPkg Adobe Creative Cloud recipe postinstall script

That said, you never know what AutoPkg can do until you try it and sure enough the FileCreator processor was able to pass recipe variables as part of creating a file. For more details, please see below the jump.

Read more…

Building an installer package for Privileges.app

March 20, 2019 11 comments

One of the open-source contributions by the Apple@SAP team has been Privileges.app, a tool designed to grant or take away administrator rights from accounts on macOS. The general idea behind Privileges is that it allows people to work with the account privileges of a standard user for day-to-day use, but allows them to get administrator rights when needed.

Documentation for Privileges.app can be found at the GitHub repo which hosts it, which is available via the link below:

https://github.com/SAP/macOS-enterprise-privileges

However, one item not included in that documentation is how to package it for deployment. Instead, AutoPkg recipes were written and made available to automate the packaging process:


computername:~ username$ autopkg search com.github.rtrouton.Privileges
Name Repo Path
—- —- —-
Privileges.munki.recipe apfelwerk-recipes Privileges/Privileges.munki.recipe
Privileges.install.recipe rtrouton-recipes Privileges/Privileges.install.recipe
Privileges.munki.recipe rtrouton-recipes Privileges/Privileges.munki.recipe
Privileges.jss.recipe rtrouton-recipes JSS/Privileges.jss.recipe
Privileges.pkg.recipe rtrouton-recipes Privileges/Privileges.pkg.recipe
Privileges.download.recipe rtrouton-recipes Privileges/Privileges.download.recipe
To add a new recipe repo, use 'autopkg repo-add <repo name>'
computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

However, not everyone is able to use AutoPkg in their environment, so manual packaging instructions are now available here. For more details, please see below the jump:

Read more…

%d bloggers like this: