As previously discussed, a number of folks in my shop use Clarivate Analytics’s EndNote bibliography software. Clarivate Analytics provides EndNote X8 with an installer application, but I need an installer package in order to easily deploy it to my customers. EndNote X8 was initially problematic in that regard, but I was able to write AutoPkg recipes for EndNote X8 to handle converting Clarivate Analytics’s installer application into a deployable installer package, including a recipe that would automate uploading the latest EndNote installers to my Casper server.
Once AutoPkg was able to provide an EndNote X8 installer package for deployment, the remaining hurdle was that the EndNote X8 installer from AutoPkg installs an unlicensed copy of EndNote and I needed to have installed copies of EndNote automatically use my shop’s EndNote site license.
Fortunately, EndNote X8’s volume license can be deployed just like EndNote X7’s volume license. The volume license is stored in as an invisible file named .license.dat in /Applications/EndNote X8 and it has a format that looks like this:
Company Name 1234567890 V2ZMQT6556P8WMH38MTQ6YSM8UXCCRYQ5MDS4WJGLKMP7RGSWECBCMT77556P8WCE8KMTQ6YSMNXJCCRYQ59MD9WJGLKMCSESSWECBCMB76556P8WCU3NMTQ6YSMLUYCCRYQ5MET8WJGLKMPSMJSWECBCM57F556P8WCU3CMTQ6YSM9DECCRYQ59XSCWJGLKMPNE9SWECBCMB79556P8WCH8KMTQ6YSMDXECCRYQ5MTSMWJGLKMPYRMSWECBCB7W7556P8W
Note: The Company Name part may show up twice in your .license.dat file.
With some additional testing, I found that I could remove an existing .license.dat file (if one was present) and replace it with my shop’s site license’s .license.dat file. That allowed me to use the EndNote X8 installer produced by AutoPkg by having Casper install it, then apply our site license file as a post-installation action. For more details, see below the jump.
Recently, EndNote X8 was released. When the new version’s installer was downloaded, it was discovered to be an installer application, which can pose problems for deployment.
By itself, the change to an installer application may not have been a huge problem as long as it had options for running the installation process from the command line. However, when I checked with EndNote support about the new installer, I was told that there was no option for installing EndNote X8 on a Mac using the command line.
Since the EndNote X8 installer does not have the option of command line installation, the only real option I thought I had was to install EndNote X8, then re-package it as either a drag-and-drop install or an installer package. However, when I dug deeper into the installer, I discovered a .zip file buried inside the installer.
When expanded, this .zip file proved to be a complete install of EndNote X8.
When I ran the EndNote X8 installer, it appeared to be performing the following functions:
1. Checking for Endnote updates
2. Extracting the .zip file into a new EndNote X8 folder
3. Moving the new EndNote X8 folder into /Applications
4. Launching the EndNote X8 application, which automatically loads the EndNote X8 Customizer screen if EndNote hasn’t been configured.
For more details, see below the jump.
As part of making sure my customers have the latest version of their applications available, I use AutoPkg, JSSImporter, and AutoPkgr to ensure that as new software updates are released, they are automatically uploaded to my shop’s Casper server.
In the case of certain applications, the process of packaging can change an application which is fine when installed via a drag-and-drop installation method to one which is broken when installed via an installer package. This is due to Apple’s pkgbuild tool erroneously stripping certain metadata used by the application’s code signing. If an application is set to check for that metadata as part of its code signature verification process, this can result in the application reporting that it’s been damaged and not launching.
An example of this which I’ve run across is Labtiva’s Papers.app, a reference library application designed to collect, organize and enable citation of scientific journal articles and other reference materials. The Papers.app installation method provided by Labtiva is a drag-and-drop install, where the customer is supposed to copy the application from a disk image and into a convenient location (like /Applications.)
When the application is installed by copying it into place, there are no problems with the application and it launches normally.
When Papers.app is packaged, then installed via an installer package, an error message will appear at first launch to report that the application is damaged.
Why the difference? In the case of Papers.app, the verification of the application’s code signing appears to include verification of certain metadata which pkgbuild appears to remove as part of the packaging process. For more details, see below the jump.
One of the challenges Mac admins have to deal with are Mac application installers which don’t follow one of the following models:
In many cases, these alternate installers take the form of applications which may or may not have options for installing via command line. For those that do not have the option of command line installation, the only real option is to install the application in question, then re-package it as either a drag-and-drop install or an installer package.
However, for those installer applications that do support command line installation, this opens up the option of embedding the installer application inside an installer package and using a postinstall script to run the necessary commands for the installer application to install its files onto the Mac. I’ve used this workflow several times in the past, with some examples linked below:
- Creating a DNAStar Lasergene 13.x installer
- Revisiting Sophos Enterprise Anti-Virus for Mac 9.2.x deployment
- Deploying Sophos Anti-Virus Home Edition for Mac 9.2.x for personal use
These examples have been manually built by me on an as-needed basis as new versions are released, but wherever possible, I want to automate this process using AutoPkg. Thanks to being able to study a recently-built .pkg recipe for AccuBarcodePro created by @foigus, I was able to build recipes for AutoPkg which handle downloading and packaging the following installer applications:
For more details, see below the jump.
An issue that crops up occasionally for AutoPkg is that a vendor will release a new version of their software but be slow to update the download location which an AutoPkg recipe is looking at. Alternatively, there may be instances where a software vendor releases two versions of their software and AutoPkg only picks up one of them. A good example of this is Oracle’s Java 8, where the past few releases of Java 8 have actually had two versions of Java 8 released simultaneously.
Fortunately, if you can manually download the needed software, there is a way to leverage AutoPkg to generate the needed installer without needing to change your AutoPkg recipe. See below the jump for details.
Over the weekend of January 24th, Adobe released Adobe Flash Player 188.8.131.526 to fix a critical vulnerability. This update was available for installation via the Flash auto-update, but there was nothing available for a manual download. This lack of a separate download meant that Mac admins didn’t have a way to get an installer for distribution to the Macs in their environments.
Adobe has stated that a manual download will be available during the week of January 26, but for the moment, it appears that the auto-update mechanism is the only way Adobe is distributing this update.
Update 1-26-2015: A 184.108.40.2066 installer is now available on the Adobe Flash Player Distribution site (not linked because you gain access to the site after getting a valid Adobe Flash Player Distribution License Agreement in place.)
Update 2 – 1-26-2015: The AutoPkg download recipe for Adobe Flash has been updated to now download and decode the install_all_mac_pl_sgn.z file from Adobe’s Flash Player update feed for Macs. If you’re using AutoPkg, update your repos and you should get the changes. For more information on the actual recipe changes, see here.
Since Elliot Jordan’s presentation at JAMF Nation User Conference 2014, I’ve started using AutoPkgr in combination with Shea Craig’s JSSImporter to automatically package and upload a number of software packages to my Casper servers.
Having AutoPkgr handle this task has been great, but I’ve had to do some additional work to make sure that JSSImporter was OK with Casper using SSL certificates issued by its own internal certificate authority instead of by a third-party external certificate authority like Verisign. On top of that, the urllib3 library used by JSSImporter added a new warning that is triggered by HTTPS requests that use an certificate that can’t be validated. Since the Casper server was signing its own certificates using its own internal certificate authority, this warning was being triggered on every AutoPkg recipes’ run, which sometimes resulted in interesting emails like the one below.
I could have installed the Casper agent on the VM that I was using to host AutoPkgr, which would have installed the root certificate for the Casper server’s internal certificate authority. However, I didn’t necessarily want to have Casper manage the VM as that would have consumed one of my available Casper licenses on a machine that didn’t need management.
However, I did want to get the root certificate for the Casper server’s internal certificate authority installed on the VM. That would allow the Casper server’s SSL certificate to be recognized as a validated certificate and fix the issues I was having with not having a validated certificate.
For details on how I fixed this, see below the jump.