Removed cached package when new version is available

[charliwest]

Is there a script already out there that will remove cached packages before you cache a newer version of that software?
We want our users to log out regularlly, during log out it installs any cached packages we have. There are a few users who don't do this (read senior management with laptops, and people who 'haven't got enough time to log out!!!') with those users sometimes we end up with multiple cached packages of the same thing, firefox, thunderbird and skype recently spring to mind.
What I would like to do is add a script to pretty much every cache package policy that says if there is already a cached package with the same name delete it before caching the new one.

I know I can do something like

#!/bin/bash

rm -rf "/Libary/Application Support/JAMF/Waiting Room/$4"*

exit

with $4 being 'package name' and then we have to fill that out for each policy. But do you know a better way, or a shortcut that actually is the package name you are caching or something?

[mm2270]

Is this actually necessary? You mention the old and new packages having the same name. If so, doesn't the jamf binary simply overwrite the old pkg with the new one? I don't use caching that much and so haven't really checked that, but I would assume it would do that.
If the binary is somehow renaming the old one and leaving it on disk instead, that actually wouldn't make any sense. If that's what you're seeing, I would report that to your account manager to see if there's some issue with your setup or some unknown defect there.
The only time this really would be a problem is if the pkgs have different names, like if you name them with the date created as part of the packaging process. Otherwise, really shouldn't be an issue.

[charliwest]

Sorry I meant same package name minus the version number eg

80528 -rw-r--r--   1 root  wheel    39M Aug  6 11:09 Skype-6.19.0.442.pkg
     8 -rw-r--r--   1 root  wheel   278B Aug  6 11:09 Skype-6.19.0.442.pkg.cache.xml
 79016 -rw-r--r--   1 root  wheel    39M Oct  2 13:46 Skype-6.19.452.pkg
     8 -rw-r--r--   1 root  wheel   278B Oct  2 13:46 Skype-6.19.452.pkg.cache.xml
 79016 -rw-r--r--   1 root  wheel    39M Sep 10 11:48 Skype-6.19.pkg
     8 -rw-r--r--   1 root  wheel   278B Sep 10 11:48 Skype-6.19.pkg.cache.xml
 84264 -rw-r--r--   1 root  wheel    41M Oct 13 16:52 Skype-7.0.pkg

[ImAMacGuy]

I'd like to see this too.

[nessts]

you could just put that in the caching policy, delete Skype-oldversion if found under the maintenance section

[mm2270]

Using a script as you posted above is going to be the most reliable way to do this. Or something like what nessts posted above.

The only way you could semi automate this would involve making absolutely certain your policy names have the same (partial) string in them as the package names AND also that your packages have the name of the application in them that would match something in the policy name. For example, using your Skype example above, if the policy name has the word Skype in it somewhere, like "Install Skype" or "Skype 6.19.0.442" and the packages all have the term "Skype" or "skype" in them, like with your example.

If so, you could try something like this as a Before script. Since the jamf.log will have the policy name in it as it runs, if we grab the running policy name and do a partial string match on any cached items using that, we can target the correct packages to rm from the folder and potentially leave any others. Its a little dangerous though since, if you're not careful how you name stuff, you could end up matching other valid caches and deleting those as well.
But give this a try. Test, test and do more testing, since this is deleting items. Be careful.

#!/bin/bash

currPolicyName=$(awk -F'Policy ' '/Executing Policy/{print $NF}' /private/var/log/jamf.log | tail -1)

if [ -d "/Library/Application Support/JAMF/Waiting Room/" ]; then
    while read cache; do
        if [[ $(echo "$cache" =~ "${currPolicyName}") ]]; then
            echo "Previous cache found. Deleting ${cache}..."
            rm -Rfd "/Library/Application Support/JAMF/Waiting Room/$cache"
        else
            echo "The cache file is not a previous version. Skipping it."
        fi
    done < <(ls "/Library/Application Support/JAMF/Waiting Room/")
else
    echo "No Waiting Room directory, so no cached packages"
fi

Edit: Changed the rm line to account for both flat files and bundle packages.

[charliwest]

@nessts where is that? I looked under maintenance and don't see an option to remove previous version, there is flush caches, but none are for cached packages.

@mm2270 will play some more with this script, its a nice idea, when I tested though it deleted all cached packages in the waiting room :)

I think a call to the api for cached packages names might be a way to go as well... not great with api calls though.

[mm2270]

@dwest, yeah, you're correct. I finally discovered my syntax isn't correct and it ends up matching all files in the Waiting Room folder when I tested it later yesterday. So don't bother playing with it anymore. :)
I'm not sure if it can effectively be done with a script like that, unless your policy names and packages names are nearly identical. I'm guessing that won't always be the case though. In brief playing with it, I couldn't get it to work right.

I was thinking the API might help here as well, but I'm not certain. Although you can get a bit of info on package names and such, I'm not clear how it will help you determine if the existing cached packages are older than the ones you're pushing in your policy.

[charliwest]

We use autopkg with version numbering, so we can scope to do you have the newest version installed or cached if no cache, before cache runs a script will delete files in the waiting room called Skype*

Ideally i would like the script to grab the name of the package from the policy that is running itself, but I don't think that will be possible, so I will just go with it as an option you have to set in the policy against the script, so my FLS guys will just have to remember to put that in correctly.

If I crack it I will post up the results here. Thanks @mm2270 for taking a look