Archive
Building a Privileges installer package using AutoPkg
In working with folks who want to build installer packages to install the Privileges app, I’ve noticed that a number of them have experienced problems with manually building an installer package for Privileges which correctly installs the Privileges app’s helper tool.
The result of an installer which does not install the helper tool correctly is that when a user requests administrator privileges using the Privileges app, the app prompts them to install the helper tool. This requires administrative rights, which sets up a chicken and egg situation where admin privileges are being required to get admin privileges.
Fortunately, there is an automated method for building the installer package which (so far) has worked correctly in each case I’m familiar with. There are AutoPkg recipes available for creating a Privileges installer package and AutoPkg is able to build a correctly working Privileges installer package.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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$ |
For more details, please see below the jump.
Using custom variables in an AutoPkg recipe to set version information
As part of a recent task to build an AutoPkg recipe which creates an installer package for a screen saver, I ran into an issue. The vendor, for reasons that no doubt make sense to them, split the version information for the screen saver across two separate keys:
- Major part of the version number: Stored in the CFBundleShortVersionString key of the screen saver’s Info.plist file
- Minor part of the version number: Stored in the CFBundleVersion key of the screen saver’s Info.plist file
What this meant is that for version 1.4 of the screen saver, the version information was stored as follows:
- CFBundleShortVersionString key: 1
- CFBundleVersion key: 4
Getting this information was not the problem. AutoPkg includes a PlistReader processor which allows multiple values to be read from one plist file, so I used it as shown below to read the CFBundleShortVersionString key’s and the CFBundleVersion key’s values and store them in the following variables:
- CFBundleVersion key: minor_version
- CFBundleShortVersionString: major_version
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<dict> | |
<key>Arguments</key> | |
<dict> | |
<key>info_path</key> | |
<string>%pathname%/Carousel Cloud.saver/Contents/Info.plist</string> | |
<key>plist_keys</key> | |
<dict> | |
<key>CFBundleVersion</key> | |
<string>minor_version</string> | |
<key>CFBundleShortVersionString</key> | |
<string>major_version</string> | |
</dict> | |
</dict> | |
<key>Processor</key> | |
<string>PlistReader</string> | |
</dict> |
So now I had the version info (in separate pieces) and now I needed to put them together. The problem I was seeing was that my usual solution, AutoPkg’s Versioner processor is set up to read one value from a plist file. I had two values and neither were in a plist file.
Fortunately, there are multiple ways to solve this problem. The first I thought of was to build a new plist as part of the recipe’s run and put the version information in. The workflow works like this:
1. Use the PlistReader processor to read the desired information.
2. Use the FileCreator processor processor to create a new plist file with the version information formatted as needed.
3. Use the PlistReader processor to read the version information out of the newly-created plist file.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<dict> | |
<key>Arguments</key> | |
<dict> | |
<key>info_path</key> | |
<string>%pathname%/Carousel Cloud.saver/Contents/Info.plist</string> | |
<key>plist_keys</key> | |
<dict> | |
<key>CFBundleVersion</key> | |
<string>minor_version</string> | |
<key>CFBundleShortVersionString</key> | |
<string>major_version</string> | |
</dict> | |
</dict> | |
<key>Processor</key> | |
<string>PlistReader</string> | |
</dict> | |
<dict> | |
<key>Processor</key> | |
<string>FileCreator</string> | |
<key>Arguments</key> | |
<dict> | |
<key>file_path</key> | |
<string>%RECIPE_CACHE_DIR%/com.companyname.carouselcloudscreensaver.plist</string> | |
<key>file_mode</key> | |
<string>0755</string> | |
<key>file_content</key> | |
<string><?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0"> | |
<dict> | |
<key>complete_version</key> | |
<string>%major_version%.%minor_version%</string> | |
</dict> | |
</plist> | |
</string> | |
</dict> | |
</dict> | |
<dict> | |
<key>Arguments</key> | |
<dict> | |
<key>info_path</key> | |
<string>%RECIPE_CACHE_DIR%/com.companyname.carouselcloudscreensaver.plist</string> | |
<key>plist_keys</key> | |
<dict> | |
<key>complete_version</key> | |
<string>version</string> | |
</dict> | |
</dict> | |
<key>Processor</key> | |
<string>PlistReader</string> | |
</dict> |
This approach works, but now you have a plist file to clean up later. Another approach is to use custom variable assigning as part of another AutoPkg processor’s run. In this case, you’re using an AutoPkg processor and adding a separate argument which is probably unrelated to the other work the processor is doing, but does the value assignment work you couldn’t accomplish otherwise.
A pretty safe processor to use for this is the EndOfCheckPhase processor. The reason is that by itself, the EndOfCheckPhase processor takes no actions. Instead, it’s used as a marker in AutoPkg recipes to tell AutoPkg to stop checking for new information as part of a recipe’s run. However, even though the EndOfCheckPhase processor doesn’t take actions and doesn’t by default include Arguments values, AutoPkg will still process Arguments values if they’re defined for the EndOfCheckPhase processor. That allows custom variables to be set with values that you couldn’t otherwise set and pass them to AutoPkg. The workflow in this case looks like this:
1. Add the EndOfCheckPhase processor to the very end of the recipe.
2. Perform the desired variable assignment as an Arguments value
The reason to add it to the end is to make sure that all of the other tasks the recipe is performing are completed by the time this processor runs.
In this case, I used this method with the the EndOfCheckPhase processor in the screen saver’s .download recipe to assign the version variable to use the values of the major_version and minor_version variables, separated by a period.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<dict> | |
<key>Processor</key> | |
<string>EndOfCheckPhase</string> | |
<key>Arguments</key> | |
<dict> | |
<key>version</key> | |
<string>%major_version%.%minor_version%</string> | |
</dict> | |
</dict> |
The result for the latest version of the screen saver software is that the version variable is assigned the following value:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
'version': '1.4' |
I’ve posted the recipes which use this technique for setting version information to GitHub. They’re available via the link below:
https://github.com/autopkg/rtrouton-recipes/tree/master/CarouselCloudScreenSaver
Using AutoPkg to get the latest Jamf Protect installer and uninstaller from your Jamf Protect tenant
Jamf has enabled a new feature on Jamf Protect tenants, where you can generate a download URL for the latest Jamf Protect client installer and uninstaller. These download URLs do not require authentication, but a security identifier unique to the Jamf Protect tenant needs to be included as part of the download URL:
Once generated, the download links are formatted similar to this:
Installer:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
curl "https://jamf.protect.tenant.here/installer.pkg?security_token_goes_here" -o installer.pkg |
Uninstaller:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
curl "https://jamf.protect.tenant.here/uninstaller.pkg?security_token_goes_here" -o uninstaller.pkg |
For example, if the Jamf Protect tenant and security identifier were as shown below, the curl commands would look like this:
- Jamf Protect tenant: companyname.protect.jamfcloud.com
- Security token: c1f0d1cb-8ddc-4f36-9578-58a7388053d5
Installer:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
curl "https://companyname.protect.jamfcloud.com/installer.pkg?c1f0d1cb-8ddc-4f36-9578-58a7388053d5" -o installer.pkg |
Uninstaller:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
curl "https://companyname.protect.jamfcloud.com/uninstaller.pkg?c1f0d1cb-8ddc-4f36-9578-58a7388053d5" -o uninstaller.pkg |
Since the Jamf Protect installer and uninstaller can be downloaded from your Jamf Protect tenant, this means that it’s now possible to use AutoPkg to get the latest Jamf Protect client installer and uninstaller as soon as they are available from your Jamf Protect tenant. For more details, please see below the jump.
autopkg-conductor updated to support both JamfUploaderSlacker and Slacker AutoPkg processors
As part of my preparations for Jamf’s planned authentication changes to the Classic API, I’ve been working more with the JamfUploader AutoPkg processors for Jamf Upload. These processors have emerged as a successor to JSSImporter, the original tool available to upload installer packages and other components to Jamf Pro using AutoPkg.
As part of my work with Jamf Upload, I’ve also updated my autopkg-conductor script to allow the use of either Jamf Upload’s JamfUploaderSlacker AutoPkg processor or JSSImporter’s Slacker AutoPkg processors. For more details, please see below the jump.
Querying an API for AutoPkg download URLs
As part of working on a new AutoPkg download recipe today, I very quickly got stuck on a problem. The app in question is Poly’s Lens software and its download page uses JavaScript to provide the download URL for the latest version of the Lens software. While this may have benefits for the vendor, this means I can’t scrape the page for the download URL’s address using AutoPkg.
Discussing the issue in the #autopkg channel of the MacAdmins Slack, folks started poking around the Lens app and discovered that it was using the Squirrel framework to provide software update functionality to the app. Assuming that meant that the app would phone home for updates, ahousseini was kind enough to monitor the app’s HTTP and HTTPS traffic using CharlesProxy. Shortly thereafter, he reported seeing Lens send the following API request using curl:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
curl \ | |
-H 'Host: api.silica-prod01.io.lens.poly.com' \ | |
-H 'accept: application/json, text/javascript, */*; q=0.01' \ | |
-H 'content-type: application/json' \ | |
-H 'origin: https://www.poly.com' \ | |
-H 'apollographql-client-name: poly.com-website' \ | |
-H 'accept-language: en-GB,en;q=0.9' \ | |
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.3 Safari/605.1.15' \ | |
-H 'referer: https://www.poly.com/' –data-binary '{"query":"\n query {\n availableProductSoftwareByPid(pid:\"lens-desktop-mac\") {\n name\n version\n publishDate\n productBuild {\n archiveUrl\n }\n }\n }"}' \ | |
–compressed 'https://api.silica-prod01.io.lens.poly.com/graphql' |
This HTTPS traffic was Lens sending an API request to see if it was running the latest version of the software. The relevant parts from our perspective were the items shown below:
This told us what format we should expect API output to be (in this case, JSON):
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
-H 'content-type: application/json' |
This told us the query which was being sent to the API endpoint:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
–data-binary '{"query":"\n query {\n availableProductSoftwareByPid(pid:\"lens-desktop-mac\") {\n name\n version\n publishDate\n productBuild {\n archiveUrl\n }\n }\n }"}' |
This told us the API endpoint:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://api.silica-prod01.io.lens.poly.com/graphql |
Putting this information together, the following curl command gets a response from the API endpoint:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
curl 'https://api.silica-prod01.io.lens.poly.com/graphql' -H 'content-type: application/json' –data-binary '{"query":"\n query {\n availableProductSoftwareByPid(pid:\"lens-desktop-mac\") {\n name\n version\n publishDate\n productBuild {\n archiveUrl\n }\n }\n }"}' |
The API response looks similar to this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{"data":{"availableProductSoftwareByPid":{"name":"Poly Lens Mac – 1.1.11","version":"1.1.11","publishDate":"2022-02-02T17:01:41.503Z","productBuild":{"archiveUrl":"https://swupdate.lens.poly.com/lens-desktop-mac/1.1.11/1.1.11/PolyLens-1.1.11.dmg"}}}} |
Part of the API response’s output includes the download URL for the latest version:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://swupdate.lens.poly.com/lens-desktop-mac/1.1.11/1.1.11/PolyLens-1.1.11.dmg |
Now that we have this information, how to use it with AutoPkg? For more details, please see below the jump:
Session videos from Jamf Nation User Conference 2021 now available
Jamf has posted the session videos for from Jamf Nation User Conference 2021, including the video for my AutoPkg In The Cloud session.
For those interested, all of the the JNUC 2021 session videos are available on YouTube. For convenience, I’ve linked my session here.
Slides from the “AutoPkg in the Cloud” session at Jamf Nation User Conference 2021
For those who wanted a copy of my cloud hosted-AutoPkg talk at at the Jamf Nation User Conference 2021 conference, here are links to the slides in PDF and Keynote format.
Using AutoPkg to create an installer package for SAP GUI
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:
- AutoPkg
- The SAP GUI recipes from the rtrouton-recipes repo
- The latest SAP GUI installer application’s disk image
- A SAP GUI templates.jar file (optional)
For more details, please see below the jump.
Installer package identifiers and the mystery of the missing Java 11 files
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.
Slides and video from the “AutoPkg in the Cloud” session at MacSysAdmin 2021
For those who wanted a copy of my cloud hosting for AutoPkg talk at at the MacSysAdmin 2021 conference, here are links to the slides in PDF and Keynote format.
The video of my session is available for download from here:
Recent Comments