Archive

Archive for the ‘Packaging’ Category

Deploying a pre-configured F5 Big-IP VPN client

July 27, 2017 Leave a comment

As part of a discussion with a colleague, he said that he needed to build an installer for his shop’s F5 Network’s VPN service but wasn’t sure how. I hadn’t built one of these previously either, so I decided to look into it.

Fortunately, F5 Networks has made the process of creating one a fairly straightforward process, assuming that your VPN administrator can provide the needed config_tmp.f5c configuration file. Assuming that you can get that file, all that’s needed is making sure that the config_tmp.f5c file is located in the same directory as the VPN client installer.

Screen Shot 2017 07 26 at 8 27 48 PM

The reason for this is that the postinstall scripts of the F5 VPN client installer are set to look for that file in that location, and will automatically import the configuration file’s contents if the file is found.

Screen Shot 2017 07 26 at 8 16 13 PM

Once I had both the config_tmp.f5c config file and a copy of the F5 VPN client installer, I was able to create an installer using this method that handled both the installation and the automated configuration of the F5 VPN client. For more details, see below the jump.

Read more…

Slides from the “Payload-free Packages: Bundle vs Flat” QuickTalk at MacDevOpsYVR 2017

June 6, 2017 Leave a comment

For those who wanted a copy of my payload-free package QuickTalk at the MacDevOpsYVR 2017 conference, here are links to the slides in PDF and Keynote format.

PDF – https://tinyurl.com/MacDevOpsPkgPDF

Keynote – https://tinyurl.com/MacDevOpsPkgKey

Preparing EndNote X8 for deployment using AutoPkg

November 15, 2016 3 comments

As previously discussed here, one of the software packages used in my shop is Clarivate Analytics’ EndNote bibliography software.

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.

Screen Shot 2016 11 14 at 9 09 31 PM

Screen Shot 2016 11 14 at 9 09 27 PM

Screen Shot 2016 11 14 at 9 24 58 PM

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.

Screen Shot 2016 11 14 at 9 10 04 PM

When expanded, this .zip file proved to be a complete install of EndNote X8.

Screen Shot 2016 11 14 at 9 11 41 PM

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

Screen Shot 2016 11 14 at 9 26 38 PM

3. Moving the new EndNote X8 folder into /Applications

Screen Shot 2016 11 14 at 9 26 40 PM

4. Launching the EndNote X8 application, which automatically loads the EndNote X8 Customizer screen if EndNote hasn’t been configured.

Screen Shot 2016 11 14 at 9 26 01 PM

For more details, see below the jump.

Read more…

Apple Setup Assistant and First Boot Package Install Generator.app

June 22, 2016 2 comments

A while back, I built an Automator application named First Boot Package Install Generator.app. It’s designed to generate installer packages, where the generated packages in turn serve as a delivery mechanism to enable other installer packages to be installed when a Mac boots up.

As part of the process of installing the other installer packages, an application named LoginLog is supposed to open over the login window and display a log of what actions are taking place, what is being installed and whether that particular installation succeeded or not.

Screen shot 2014 10 19 at 2 39 21 pm

For the most part, this process of launching LoginLog and displaying the log works as designed but it was brought to my attention that there was one scenario where LoginLog did not appear as expected. When a firstboot package created by First Boot Package Install Generator.app was installed onto a new installation of OS X El Capitan, LoginLog did not appear over the Setup Assistant.

Screen Shot 2016 06 21 at 8 11 00 PM

The reason it didn’t appear is because the LaunchAgent for LoginLog is triggered by the Mac being at the login window.

Screen Shot 2016 06 21 at 8 04 30 PM

However, Apple’s Setup Assistant on El Capitan no longer runs over in the context of the login window. Instead, it runs in the context of an account named Setup User.

Screen Shot 2016 06 21 at 8 07 23 PM

In order to have LoginLog appear again in this scenario, I needed to develop a method which could accomplish two tasks:

  1. Suppress Apple’s Setup Assistant during the time when I wanted the LoginLog application to appear.
  2. Avoid interfering with an otherwise desired launch of the Apple Setup Assistant.

For more details, see below the jump.

Read more…

Diagnosing and fixing code signing issues for applications installed by installer packages

June 6, 2016 Leave a comment

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.

As part of this process, some applications need to be converted by AutoPkg from using the drag-and-drop installation method provided by the vendor to now being installed using an installer package.

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.)

Screen Shot 2016 06 05 at 6 16 42 PM

 

When the application is installed by copying it into place, there are no problems with the application and it launches normally.

Screen Shot 2016 06 05 at 1 55 34 PM

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.

Screen Shot 2016 06 05 at 4 58 14 PM

 

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.

Read more…

Using AutoPkg to build installer packages from installer applications

May 24, 2016 Leave a comment

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:

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.

Read more…

Creating a DNAStar Lasergene 13.x installer

March 17, 2016 7 comments

As part of my day job, I support some medical research software packages that most Mac admins have likely never heard of. One of these software packages is DNAStar‘s Lasergene software suite. Up until now, this software used an Installer VISE installer, which required me to completely repackage the software for deployment. However, as of Lasergene 13.x, DNAStar has switched to using Bitrock’s InstallBuilder for the Lasergene installer. This tool does not produce standard installer packages, but InstallBuilder installer applications do support installation and uninstallation via the command line. That allows me to run an installation or uninstallation of the Lasergene suite by using the commands shown below:

To install a copy of DNAStar Lasergene which uses a network license server:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --mode unattended

To install a copy of DNAStar Lasergene which uses an individual license code:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --dnastarProductKey XXXXX-XXXXX-XXXXX

To uninstall DNAStar Lasergene:

"/Applications/DNASTAR/Uninstall Lasergene 13.app/Contents/MacOS/installbuilder.sh" --mode unattended

While this installation method is still not ideal, I can at least script it. That makes it an improvement over the hand-crafted installers I previously had to create for Lasergene.

Unfortunately, there is a quirk of Lasergene’s installation process which carries over from the Installer VISE days, which is that the Lasergene installer assumes that the account running the installation is going to be the owner of the application. So if you install Lasergene as your local admin, that may mean that your users aren’t able to run the Lasergene applications because they may not have permission to run the applications or access one or more of the application data files.

To address both the installation and permissions issues, I was able to create an installer using this method that handles both the installation and then fixing the permissions as a post-installation task. For more details, see below the jump.

Read more…

%d bloggers like this: