Automating an AutoPkg Munki import when vendors don’t package installers properly


You may have, when using (or creating) a .munki AutoPkg recipe, come across a situation in which you run it:

autopkg run -v NAMEOFITEM.munki
and then get something back like this:
Item NAMEOFITEM already exists in the munki repo as OLDNAMEOFITEM.
even though you’re sure the item is newer than the one in the Munki repo.

That has to do with the find_matching_item_in_repo() function the MunkiImporter processor uses to determine whether the item exists already or not.

It compares a number of things between the to-be-imported item and what’s already in the Munki repo—installer item hash, installs, receipts, files and paths, etc. If any of those matches up, MunkiImporter considers it a match.

So, for example, if you have BADLYPACKAGEDBYVENDOR 3.7.3, which is an update for BADLYPACKAGEDBYVENDOR 3.7.2, but the receipts for both are just 1 (yes, 1 and not 3.7.2 or 3.7.3), the MunkiImporter processor will see the two as the same and not do “another” import of the same item. Likewise, if the version in the app bundle is 3.7 and not 3.7.2 or 3.7.3, the MunkiImporter processor will see them as the same. I’ve even run into situations in which a vendor artificially ups the number but the “new” package or .app bundle is exactly the same. In that case, the installer hash will be the same, and the MunkiImporter processor will see them as the same.

So what do you, apart from complain to the vendor and pray it fixes the problem?

There may not be anything you can do apart from force an import. You may find a convoluted workaround, though. For LockDown Browser, I had to create an installs array based on the executable and also essentially override the useless receipts array. You might have to do something similar, depending on how bad the vendor package is.


15 responses to “Automating an AutoPkg Munki import when vendors don’t package installers properly”

  1. So I’ve tried out your recipe, it downloads Lockdown okay, and generates the package seemingly ok. However after installing it on my test machine, I get an error on launch “Unable to Find the server settings”. It appears that the id.txt file isn’t being generated correctly. All that’s in the file is “LockDownB:no”

    • Yeah, I ran into that recently and essentially had to create an update_for Munki item that put the proper id.txt file in there.

    • I unpacked the original .pkg file, and from the postinstall file, it looks like the id.txt file is generated based on the original package name which may be where the issue is coming in.

      • Wow. That’s some horrible packaging! Yikes. So it may be that my renaming the .pkg wasn’t such a great idea.

        I’ll see if I can rectify that to account for their horrible packaging…

      • On a hunch, I renamed the package to the original filename as downloaded from respondus, installed it, and it worked ok.

        Last comment I swear.

        Thank you for your work though, your blog has been quite useful.

        • Thanks for the heads-up about the ridiculous way Respondus made this .pkg. I’ve adjusted the .munki recipe, and it should be good now.

          • I figured out the “problem,” which is Munki automatically appends the version number to the name of the .pkg installer, so that then changes the name. I suppose I could create a .dmg to put the .pkg in… this is getting kind of ridiculous…

          • Amazing that such a workaround was necessary, but the .dmg trick worked. Absolute latest version of the .munki recipe should now work. Thanks for the heads-up about the bad vendor packaging.

  2. Happy to help.
    The newest .munki worked, with one small hitch, it didn’t clean out the previously renamed version from the cache folder, so it bundled both into the .dmg.

    Munki ran the renamed one during the install and of course didn’t work right. Cleaned the cache folder out and tried again and all went well.

    This could cause issues down the road with newer versions, may want to clean the cache folder out before beginning the download.

      • I suspect the old non-working .pkg that didn’t get cleaned out got into the .dmg, which may be a .pkg that Munki installs. Let me see if I can work some housecleaning into the recipe.

      • Should be good now. I added in a PathDeleter processor to the download recipe. I had been under the impression that purge_destination would clear out the directory contents before extracting the .zip file, but apparently not.

      • Never mind. I realized I made a silly mistake and didn’t have the Unarchiver arguments in a dict, so that’s why purge_destination wasn’t happening.

Leave a Reply to Graham Perkins Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.