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.

Posted

March 13, 2017

Uncategorized

alanysiu

Tags:

autopkg, munki, troubleshooting

Comments

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

Graham Perkins

April 13, 2017

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”

Reply
1. Alan Siu
  
  April 13, 2017
  
  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.
  
  Reply
2. Graham Perkins
  
  April 13, 2017
  
  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.
  
  Reply
  1. Alan Siu
    
    April 13, 2017
    
    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…
    
    Reply
  2. Alan Siu
    
    April 13, 2017
    
    By the way, the id.txt contents are essentially the institution ID.
    
    Reply
  3. Graham Perkins
    
    April 13, 2017
    
    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.
    
    Reply
    1. Alan Siu
      
      April 13, 2017
      
      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.
      
      Reply
      1. Alan Siu
        
        April 13, 2017
        
        Spoke too soon. There may be another change I have to make…
      2. Alan Siu
        
        April 13, 2017
        
        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…
      3. Alan Siu
        
        April 13, 2017
        
        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.
Graham Perkin

April 17, 2017

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.

Reply
1. Graham Perkin
  
  April 17, 2017
  
  Well, the package got created right, when it installs the id.txt isn’t there for some reason.
  
  Reply
  1. Alan Siu
    
    April 19, 2017
    
    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.
    
    Reply
  2. Alan Siu
    
    April 19, 2017
    
    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.
    
    Reply
  3. Alan Siu
    
    April 19, 2017
    
    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.
    
    Reply