Using Munki to revert or downgrade software

Introduction

It might come as little surprise to find out that I use Munki in my organization to manage software installations on macOS.

Munki is really good at keeping software up-to-date. Every time it runs, it compares the versions it has on the server against the versions installed on the local machine and updates any software at a lower version than it has on the server.

Its default behavior when an item on the local machine has a higher version than that on the server is to leave it alone. This is great when you have users that for whatever reason need to test newer versions (or perhaps they are actually developing the newer version of the software).

I also use AutoPkg to automate finding new software updates and to import them into my Munki repo. For us, AutoPkg checks on approximately 50 items each day, importing anything new into my Munki repo into a testing catalog.

On Tuesday of this week, Mozilla released Firefox 59. AutoPkg found the new release and imported it into Munki as expected. On Wednesday, I noticed that AutoPkg had imported Firefox 60! I looked at the installed application, and its version was actually 60.0b3. Someone at Mozilla had goofed and pointed the “latest firefox release” link at the 60 beta. Later in the day this goof was remedied and the link once again returned Firefox 59.

But my AutoPkg run had occurred while the Mozilla site was offering 60.0b3, and so it was downloaded and added to my Munki’s repo’s testing catalog. 25 Macs in my organization (including my own laptop) now had Firefox 60.0b3 installed.

(Side note: because of the way Munki does version comparisons, when the final release of Firefox 60 comes out, if it is versioned as “60.0”,  Munki would not “upgrade” from 60.0b3 to 60.0 – “60.0b3” compares as higher than “60.0”.)

I wanted to configure Munki to downgrade any install of Firefox 60.0b3 to Firefox 59. Since by default Munki leaves higher versions alone, this is not exactly obvious how to do.

Advertisement

Firefox 10 ESR and CCK notes

Nick McSpadden has posted some notes about using the Firefox CCK to manage Firefox 10 ESR here:

http://groups.google.com/group/macenterprise/browse_thread/thread/614aab9bde90485a#

It grates on me that (since about version 8) any time a new version of Firefox is released, I get to choose between the following evils:

1. Repackage Firefox.
2. Run a script or install an auxiliary package after installing a new version of Firefox.
3. Leave Firefox unmanaged.

This problem isn’t so bad if your machines are pretty tightly managed, but if your users can upgrade Firefox on their own or have figured out they can run Firefox from any location they have write access to, then Firefox is essentially unmanageable.

Firefox global extensions, again

Previously, I have written on deploying Firefox extensions globally, and using the Firefox Client Customization Kit (CCK) to customize Firefox for your organization.

Using the CCK involves creating a Firefox extension, and most likely, you’ll want to deploy it globally. A few commenters on the CCK post were confused about the details around that, so this post is an attempt to clear all that up.

More Firefox customization

I’m experimenting with a new (to me) method of delivering configuration settings for Firefox.

Previously I was inserting custom configuration files into the application bundle.

While this worked, it had a significant disadvantage. In order to be able to install new versions of Firefox without deleting these inserted files, I had to repackage new Firefox releases. This is very easy and takes little time, but is still more work than zero. I wanted to see if I could make things more modular, so I could install Firefox from the Mozilla disk image without having to repackage it.