Re-download a pkg when a condition is met using the API

[ttl]

Does the API support such a scenario?

We're seeing some instances where something like a printer driver gets lost (as of right now, assuming it's something the user is doing because it's not widespread, but happens enough that it's gotten to be something we'd like to script a fix for) and because those are sent as a pkg, they don't get re-downloaded on verify.

• After the pkg is installed, the original installer disappears.
  • In /usr/local/etc/FileWaveInstallers/FlatPackage-958_658e_558_368_367_109.pkg on first deployment, there's a 21MB file: 958_658e_558_368_367_109.pkg
  • After installation, 958_658e_558_368_367_109.pkg is gone and only FileWave.plist remains
• If, on verify, a condition is met in a bash script, I'd like to re-download 958_658e_558_368_367_109.pkg and install it
• Alternatively, is there a flag to set on the pkg to leave it behind after installation so I can simply point the script to it & re-run?

 

The API documentation seems to only reference querying and obtaining report-like data: https://fwkb.atlassian.net/wiki/spaces/KB/pages/4328035/RESTful+API

[Sean]

FileWave won't remove the PKG, unless the file is set to either 'Self Healing' or 'Download if missing' and then the association is removed.  However, there is nothing to stop the developer of the PKG adding additional code to remove the PKG after installation; the PKG shouldn't be required anymore after the drivers are installed.  It is a sneaky way to ensure you always download the latest driver if you need to reinstall.

You don't have to build a PKG Fileset though, you could build an empty Fileset and add the PKG as just another file.  From here you would then add a Fileset Script to run the PKG.  If that Fileset Script was a Verification Script, then it would run on every Verify.  Additionally, if the PKG itself was also set to either 'Self Healing' or 'Download if missing', then if it had been removed, the verification would put it back.

Of course, you could avoid the re-download if the installer is removing itself.  Add a copy command in the script for the PKG, run the PKG installer command against the copied version, then the PKG will always be on the device, since the copied one would be the one removed.

The weird part is the driver missing.  Why would a user even want to remove a printer driver?  Are these shared devices, so you don't know who is removing the driver?

You could in theory have a timed script to monitor the existence of the actual driver files and if removed cause an action, e.g Slack/Teams notification.

The only times I have seen things mysteriously 'disappear' are:

• AV Software quarantining 
• An Actual Virus
• Another Fileset that has the files at file level, set as self-healing and that Fileset becomes disassociated
• The Fileset has an uninstaller script to remove items and the Fileset is disassociated by mistake
• Another product like, .e.g. DeepFreeze, which is restoring the device to a known state and that known state does not include those files.

Hopefully the verification script method will provide you with your original desire, but also perhaps the other information might help you to locate the original cause.

 

[ttl]

These are very good suggestions, thank you!

 

Quote

The weird part is the driver missing.  Why would a user even want to remove a printer driver?  Are these shared devices, so you don't know who is removing the driver?

That's what I haven't been able to figure out.
I added a bunch of additional checks to the script that builds the queue and so far, I haven't seen any missing drivers - but rather the odd queue with the wrong case.

For example: library instead of Library

Users don't have admin, so they shouldn't be able to remove anything in the system directories, which is where the drivers install to.

I did see 1 user who added a network shared printer that was causing a false-positive on the queue they kept trying to use.. so the queue was visually there, but when actually viewing their print list via lpstat -p it shown as something like: library__assettag_123

Unfortunately, users DO have the ability to add printers, because many do work from home and insist on needing to add their home printer.

We do use Sophos for AV, which has done some strange things in the past, but unless it was more widespread I don't think it's Sophos' fault.