Deploying FontAgent Pro (and Smasher) using Munki

Zach Tarr — Thu, 18 Feb 2016 01:41:04 +0000

Many of the clients I work with use FontAgent Pro for font management. Unfortunately, setting it up has previously been a manual process that involved touching each workstation to install, license and configure the app. Here are some things that I have done to start to automate this a bit.

Note: While everything seems to work ok in my tests, I have not rolled any of this out in production yet. I will edit this once I do the next deployment. YMMV.

AutoPkg

I wrote an AutoPkg recipe for FontAgent Pro 6 here.

Insider Software publishes a single link that always points to the latest release. The release is packaged as a .pkg inside of a .dmg, which means the recipe is pretty basic. Except for one thing- Smasher.pkg is bundled into the same .dmg.

When the install is done through Munki, both FontAgent Pro and Smasher are installed. However, if you trigger an uninstall through Munki, it only removes FAP. To address this, I added a one-line post-uninstall script to the .munki recipe that triggers the Smasher uninstall script in /Applications/Smasher/Uninstall.app/Resources/.

License

When FontAgent Pro is activated, it drops two files (Activation and Registration) into /Library/Application Support/FontAgent Pro/. If you are using a volume license, you can copy these files to the same location on another Mac to complete the activation. This was suggested to me by Insider Software as the best way to deploy the license to multiple Macs.

To do this in a repeatable fashion, I made a template Makefile for The Luggage. This way I can simply copy the Activation and Registration files into the same directory as the Makefile, edit the TITLE and REVERSE_DOMAIN at the top of the Makefile, and run ‘make pkg’.

Smasher works the same way, although it only requires the Registration file.

Updates

I don’t want the built in updater to run. I made a .mobileconfig profile using mcxToProfile, and then stripped out every preference except for ‘CheckForUpdatesAutomatically’ to accomplish this.

Here is a profile for Smasher as well.

Deployment

All 3 of these pieces (the application, the activation pkg, and the profile) can be deployed with Munki (or in my case, Gruntwork) to the correct workstations. When users launch the application, they just have to click through the initial setup screens, and then login to the font server with their credentials.

Future Plans

I’d love to streamline this process even more, especially by bypassing the initial setup screens and auto-installing the Adobe Plugins.

osx-userpkg-preinstall-check

Zach Tarr — Sat, 16 Jan 2016 20:21:03 +0000

One goal we have at the office is to setup consistent local admin accounts across every Mac at each of our clients offices. I created a some packages with CreateUserPkg to accomplish this, and I have been installing them on every new Mac I setup. Going forward, my plan was to deploy them using Munki. However, I ran into one problem:

Because many of these Macs were around before we started using the CreateUserPkg package, they already have a local admin account that was created manually. This account may conflict with the package in some way.

I wrote a very simple shell script to solve this problem. It first checks to see if an account with the given shortname exists. If it doesn’t, then it exits with code 0. If it does, it compares a given UID and UUID to those of the local account on that Mac. It either reports back a conflict and exits with code 1, or it gives you the go-ahead to install the package and exits with code 0.

It can be run locally or via ARD, but I plan on using it as a Preinstall Script in Munki.

I put this up on GitHub

Hello world.

Zach Tarr — Wed, 25 Nov 2015 03:30:10 +0000

I have a blog now.